Firestore: pending writes silently lost when issued around disableNetwork() / enableNetwork()

[eli1stark]

[REQUIRED] Step 1: Describe your environment

• Android Studio version: any (reproduced on emulator and physical device)
• Firebase Component: Firestore
• Component version: reproduced with firebase-bom:33.1.1 (firebase-firestore); originally observed June 2024, still relevant as of the FlutterFire triage in July 2026

[REQUIRED] Step 2: Describe the problem

Steps to reproduce:

When a write (e.g. update() with FieldValue.increment()) is issued while the network is being toggled via disableNetwork() / enableNetwork(), the write can be silently dropped — it never reaches the backend and no error is surfaced. Starting from a field value of 0, calling increment(-1) followed by increment(+1) across a network toggle can leave the server value at -1 (or lower after repeated runs) instead of 0.

This was originally reported against FlutterFire in firebase/flutterfire#12952 with a Flutter reproduction (roughly 40–50% hit rate per attempt, near-certain when repeated). A FlutterFire maintainer then reproduced it in a pure native Android project using this SDK directly, with no Flutter involved: TarekkMA/firebase-android-reproduction @ ff-issue/12952. On that basis the FlutterFire issue was closed as an upstream native SDK bug (comment) — FlutterFire only forwards increment/disableNetwork/enableNetwork to this SDK. I'm filing this issue here to continue the investigation, as no upstream issue existed yet.

Trigger sequence (from the original report, translated to the Android SDK):

FirebaseFirestore db = FirebaseFirestore.getInstance();
DocumentReference doc = db.collection("test").document("doc"); // field "v" starts at 0

Map<String, Object> minusOne = new HashMap<>();
minusOne.put("v", FieldValue.increment(-1));
Map<String, Object> plusOne = new HashMap<>();
plusOne.put("v", FieldValue.increment(1));

doc.update(minusOne);      // not awaited, as in real offline-capable apps
db.disableNetwork();
doc.update(plusOne);
db.enableNetwork();

Repeat the sequence a few times (a 2–3 second pause between runs is enough; firing many sequences concurrently makes it near-deterministic) and watch the document via a snapshot listener or the console.

The disableNetwork()/enableNetwork() calls are only a deterministic stand-in for an unstable real-world connection — the original report reproduced the same loss on a physical device with a genuinely flaky network, it is just far more cumbersome to trigger that way.

Expected result

Both queued writes are eventually delivered once the network is re-enabled — offline mutations are documented as queued and synced when connectivity returns. The field ends at 0 after every -1/+1 pair, every time.

Actual result

Intermittently (~40–50% of attempts in the Flutter harness, also confirmed in the native Android repro linked above) one of the writes is lost: the field ends at -1, and repeated runs drift further negative. The lost write's task never fails — there is no error signal that the mutation was dropped, so the client and server silently diverge.

Relevant Code:

• Native Android reproduction (by FlutterFire maintainer @TarekkMA): https://github.com/TarekkMA/firebase-android-reproduction/tree/ff-issue/12952
• Original Flutter reproduction with full source and screen recording: [cloud_firestore]: missing increment updates when unstable internet connection flutterfire#12952

Note: the same behavior was also reproduced on iOS through FlutterFire, so the defect is likely shared across the native SDKs' offline mutation queue logic rather than being Android-specific.

[lehcar09]

Hi @eli1stark, thank you for reaching out. I tried to reproduce the issue and I was able to replicate the behavior. It looks to me that this is caused by a race condition. Let me consult this to our engineers and get back to you. Thanks!

[cherylEnkidu]

Hi @eli1stark,

Thank you for the detailed report and reproduction. We’ve investigated this and want to share why it happens and how to work around it:

Why this happens

1. Known backend limitation: The Firestore backend (/google.firestore.v1.Firestore/Write) currently does not support write stream resumption across connections (stream_token).
2. Duplicate replay: If a network drop or disableNetwork() occurs after the server commits a write but before the ACK reaches the client, the SDK re-transmits the unacknowledged batch upon reconnecting. Because the server cannot resume the previous stream session, it executes the batch a second time.
3. Drift on increments: Replaying idempotent writes (e.g., set(5)) is safe, but replaying relative transforms like FieldValue.increment(-1) applies the delta twice.

Next steps

We are following up with the Firestore backend team to evaluate support for write stream resumption and mutation deduplication across reconnections.

Suggested workarounds

• Use Transactions: For critical counters, use db.runTransaction(...). Transactions fail if interrupted and prevent duplicate replay across reconnections.
• Set absolute values: Use idempotent updates (e.g., setting v: 0 instead of increment(-1)) so duplicate execution converges to the same result.
• Await completion: If offline queuing isn't required, await the update task so it completes before network changes occur.

[eli1stark]

Hi @cherylEnkidu, thanks for the detailed investigation and for confirming the root cause.

A few clarifications on the workarounds, since our case is specifically offline-queued writes:

• runTransaction requires an active connection, so it can't replace queued offline writes.
• Absolute values aren't safe for counters with concurrent writers across devices — that's precisely what increment() is for.
• Awaiting the task doesn't help either: per your description the server has already committed and only the ACK is lost, so the batch is replayed and double-applied before the await resolves.

Is there a public tracking reference for the backend write-stream-resumption / mutation-dedup work we can follow?

[cherylEnkidu]

Hi @eli1stark,

You are right on all three points. Those workarounds only apply if an app can trade away either offline queuing (by requiring online transactions/awaits) or concurrent multi-device counting (by using absolute values).

We track backend feature requests in our internal issue tracker (b/540459641), which isn't publicly accessible. However, we have linked this GitHub issue directly to that internal tracking ticket, so this GitHub issue (#8440) is the best public reference to follow for updates.