Firestore query for subcollections on a deleted document

Question

When using the Firebase console it is possible to see all documents and collections, even subcollections where the path has "documents" that do not exist.

This is illustrated in the picture included here, and as stated in the docs and on the screenshot as well. These documents won't appear in queries or snapshots. So how does the console find these nested subcollections, when a query does not return them?

Is it possible, somehow, to list these documents. Since the console can do it, it seems there must be a way. And if it is possible to find these documents, is it possible to create a query that fetches all the documents that are non-existant but limited to those that have a nested subcollection? (Since the set of all non-existant documents would be infinite)

Answer 1

The Admin SDK provides a listDocuments method with this description:

The document references returned may include references to "missing documents", i.e. document locations that have no document present but which contain subcollections with documents. Attempting to read such a document reference (e.g. via .get() or .onSnapshot()) will return a DocumentSnapshot whose .exists property is false.

Combining this with the example for listing subcollections, you could do something like the following:

// Admin SDK only
let collectionRef = firestore.collection('col');

return collectionRef.listDocuments().then(documentRefs => {
   return firestore.getAll(documentRefs);
}).then(documentSnapshots => {
   documentSnapshots.forEach(doc => {
      if( !doc.exists ) {
        console.log(`Found missing document: ${documentSnapshot.id}, getting subcollections`);
        doc.getCollections().then(collections => {
          collections.forEach(collection => {
            console.log('Found subcollection with id:', collection.id);
          });
        });
      }
   });
});

Note that the Firebase CLI uses a different approach. Via the REST API, it queries all documents below a given path, without having to know their specific location first. You can see how this works in the recursive delete code here.