FirebaseFirestoreException: Failed to get document from cache. (However, this document may exist on the server. Run again without setting source to CACHE to attempt to retrieve the document from the server.)

[vlonjat-gashi]

Environment

• Android Studio version: 3.2.1
• Firebase Component: Firestore
• Component version: 17.1.4

Steps to reproduce:

When fetching from DocumentReference with Source.CACHE and the object doesn't exist in cache, Firestore SDK throws a FirebaseFirestoreException. But would it make more sense to return a null object since object not existing in cache is a valid scenario?

[mikelehen]

To be clear, is it throwing an exception? Or returning a failed Task? I'd expect the latter.

[wilhuff]

This is a tricky part of the API to get right, but there are essentially three possible results that we wanted to convey:

• Document is available
• Document is known not to exist
• Document is in an unknown state

It's the last of these that creates an exception (available via Task.getException). We'd like to preserve the ability to distinguish these last two cases for applications that need it.

A way to collapse the known-not-to-exist and unknown states is to wrap the resulting task in an adapter like the following:

Task<DocumentSnapshot> hideUnavailable(Task<DocumentSnapshot> docTask) {
  return docTask.continueWith(Executors.DIRECT_EXECUTOR, task -> {
    if (task.isSuccessful()) {
      DocumentSnapshot snap = task.getResult();
      if (snap.exists()) {
        return snap;
      } else {
        return null;
      }
    }

    Exception exception = task.getException();
    if (exception instanceof FirebaseFirestoreException) {
      FirebaseFirestoreException firestoreException = (FirebaseFirestoreException)exception;
      if (firestoreException.getCode() == FirebaseFirestoreException.Code.UNAVAILABLE) {
        return null;
      }
    }

    throw exception;
  });
}

[wilhuff]

Oh and if this really is throwing rather than returning a failed Task in this case, please let us know and we'll reopen this issue. As it stands, this is intended behavior.