Firestore: pending writes silently lost when issued around disableNetwork() / enableNetwork()
I maintainer di solito rispondono entro 1 giorno
@cherylEnkidu ci sta già lavorando.
Dal 22/7/2026.
Valutazione
Questa issue non è ancora stata valutata.
Descrizione
[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: https://github.com/firebase/flutterfire/issues/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.
- Lingua principale
- Java
- Stelle
- 2.6k
- Fork
- 733
- Merge medio
- 2g 15h
- PR unite (30g)
- 72
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di firebase/firebase-android-sdk
-
api: remoteconfig
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
firebase/firebase-android-sdk#8827 ·
I maintainer di solito rispondono entro 1 giorno
-
Crashlytics plugin writes build ID lists in directory listing order, so APKs can differ between machinesForse già presa @mrober l’ha presa 8 giorni fa. Apertaapi: crashlytics
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
firebase/firebase-android-sdk#8789 · 1 commento · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
api: auth
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
firebase/firebase-android-sdk#8505 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 15/100
firebase/firebase-android-sdk#8835 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
firebase/firebase-android-sdk#8832 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di firebase/firebase-android-sdk
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 80/100
I maintainer di solito rispondono entro 1 giorno
-
RIS export splits an organization name containing “and” into multiple authorsForse già presa @Gautam-aman l’ha presa oggi. Apertastatus: needs-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
JabRef/jabref#17821 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
FailureContext.java rounds down thresholds in lastedAtLeast()Forse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 86/100
I maintainer di solito rispondono entro 1 giorno