Sub-collections of docs with colon in the doc id are not shown

[tomsun]

If I write to a sub-collection of a non-existing doc, like so (haven't written any data to the doc region:1 prior to this):

db.collection("servers").doc("region:1").collection("instances").doc("instanceA").set({...})

...and if I navigate to the servers collection in the emulator UI, then:

1. the non-existing doc region:1 is shown in italics just as how FIrebase's web console handles the situation ✅

2. after clicking the non-existing doc region:1, it does not present any sub-collections though! ❌ whereas if I reproduce these steps in Firestore proper I can see the instances sub-collection in Firebase's web console at this point

3. if I now add the instances sub-collection via the emulator UI - at which point I am asked to also add a doc: I add the doc instanceB - then I am able to see both the instanceA doc created via code as per above and the instanceB doc 🥳 so mainly a UI listing bug of some sort: the emulator does appear to store the data of instanceA in this situation just like Firestore proper does.

4. If I reload the emulator UI browser window at this point, the instances sub-collection is hidden again, i.e. the workaround presented in 3 does not persist beyond a page reload.

[yuchenshi]

We've updated the Emulator UI to address this in a previous version, so please update the Firebase CLI to the latest version just to make sure. Just let us know the version number from running firebase --version.

[tomsun]

@yuchenshi ok nice!

I don't have anything pinned though, but perhaps my base Docker layers are several weeks old? No: tried clearing the cache and rebuilding: same results.

FROM node:12 AS emulators
RUN npm i -g firebase-tools
RUN apt-get update && apt-get install -y openjdk-8-jre git
RUN firebase setup:emulators:firestore
...

@yuchenshi do I need to run some yet-to-be-released version to get the fix, or might my issue be slightly outside of the boundaries of what the fix fixed?

[yuchenshi]

I'm not too familiar with the Docker caching mechanisms but could you please add a RUN firebase --version line right after and let me know the results? We can definitely look into this once we have the version number.

[tomsun]

@yuchenshi Still have that same container running from earlier today:

% docker exec -ti 54dc3c930f96 bash -l 
root@54dc3c930f96:/opt# firebase --version
9.11.0

Which seems to be the latest release at the time of writing, from 8 days ago

Here's a demo

https://user-images.githubusercontent.com/442510/119540187-d36f5e00-bd95-11eb-93a1-3a3e57657cb7.mov

[tomsun]

I opened the network inspector and found another clue; one of these each time I load the region:local (non-existing) doc in the UI

{
    "error": {
        "code": 400,
        "message": "Document parent name \"projects/local/databases/(default)/documents/mixers\" lacks \"/\" at index 51.",
        "status": "INVALID_ARGUMENT"
    }
}

[yuchenshi]

Thanks for the additional info! Looks like the the colon : confused the Emulator UI or Firestore Emulator REST API and thus the subcollection IDs are not correctly listed. We can definitely look into this bug. In the meantime, please test with IDs without colons for now.

[tomsun]

Nice, seems to be the colon indeed; if I create an actual existing doc with a colon in the name and give it a sub-collection, the same bug occurs. Adjusting the issue title accordingly

[j0hnsmith]

I just ran into this with the latest version (ran firebase setup:emulators:ui and it downloads ui-v1.6.2.zip)

[strom2357]

We're tracking this bug internally at b/200683067

[codewithtushar]

i am too facing same issue, for me subcollections are created but i cannot see them in UI, but if i had path of that subcollections , i can access it and see all data still there, But i didn't have colons anywhere

Update: document of root collection was having space at the start of it , recreating document and subcollection worked for me, also i am not able to delete the old document id with space in it, so living it it.

[rorystephenson]

Still an issue, @strom2357 has there been any progress in the internally tracked bug (b/200683067)?