How to Detect Absent Network Connection When Setting Firestore Document

SWIFT - How to detect Firestore connection errors / offline connection

Normally, in this state it's best to monitor network connection state of the device, instead of looking for a particular error. It won't tell you when Firebase is failing, but it will tell you when device is offline, so you can expect the failure. You can use NWPathMonitor to do that. Here is the implementation example.

And even nicer option is to enable offline capabilities of Firebase, which allows you to not worry if user is offline, and let Firebase to handle synchronization.

Detect when Firestore can not find specific object

When there is no internet connection it works great.

That's the expected behavior since, for Android, Firestore has its own offline persistence mechanism enabled by default.

When there is a problem like for e.g. there is no searching object in my Firestore database function doesn't throw any exception.

If you are creating a document reference that points to a particular document, and if you call get() and the document doesn't exist, it doesn't mand that an Exception will be thrown. And it makes sense since the absence of a document should not raise an Exception. However, if for example, that request fails due to improper security rules, then it definitely makes sense to raise an Exception.

How I can detect timeout or other errors?

Please note that read operations in Firestore never time out. Why? Because the operations never fail due to loss of network. If there is a loss of network (there is no network connection on the user device), neither the OnFailureListener nor the OnCanceledListener gets triggered. Behind the scenes, Firestore SDK tries to reconnect until the devices regain connectivity. Don't think of Firestore reads and writes as typical input and output operations.

Other errors can be caught in the way that you already do.

How to catch Client is Offline error in Flutter Firebase Firestore

With all of the Firestore client SDKs (including Flutter), errors are never thrown when a client is offline. If you're seeing an error in the log, that doesn't mean an exception is escaping from an API call. Tt just means that the SDK has chosen to log something internally. On other platforms, the SDK will also internally retry queries until the client comes back online, so I would assume the same to be true for Flutter.

Unfortunately, Firestore also does not provide a way for you to detect if you're offline.

See also: how to catch error in firestore when no internet

If you think the Flutter SDK is doing the wrong thing, I would encourage you to file a bug on GitHub.

Firestore 'await addDoc' (Web version 9) hangs forever when network connection is lost

This is the expected behavior: the promise from addDoc is only resolved once the write operation is completed on the server. If you don't want to wait for that, don't use await.

If there is a problem with the local write, addDoc will raise an exception. Only when there is a problem with the write on the server, will it reject the promise.

In v8 and before you could get the DocumentReference without await by using collection.doc(). See the last snippet in the documentation on adding a document for how to do this in v9 too:

In some cases, it can be useful to create a document reference with an auto-generated ID, then use the reference later. For this use case, you can call doc():
import { collection, doc, setDoc } from "firebase/firestore"; 

// Add a new document with a generated id
const newCityRef = doc(collection(db, "cities"));

// later...
await setDoc(newCityRef, data);
Behind the scenes, .add(...) and .doc().set(...) are completely equivalent, so you can use whichever is more convenient.

Firestore realtime updates missed while disconnected

Firestore synchronizes the state of the documents, and not necessarily all the changes in that state.

So if multiple changes happened to the SF document while you were offline, and some of the later changes erased changes that came earlier, you will not see those earlier changes. You will only see the correct current state when the connection is reestablished.

If you want to see all state changes, consider storing those actual state changes in the database (e.g. in an updates subcollection), so that none of them are overwritten by later changes to the same data.