Repository navigation
Conversation
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. |
…ng the database forever doTransaction blocked the RTDB run-loop thread on an unbounded CountDownLatch.await() until Dart replied. When the engine is destroyed, or its messenger detached, while the handler is pending, nothing replies: FlutterJNI drops messages once detached. The run-loop thread then stays blocked and every later operation on that database hangs, including in other engines of the process. Wait at most 30 seconds, as cloud_firestore does for its transactions, then abort the transaction. onDetachedFromEngine releases pending waits at once, and later calls abort without calling Dart.
A transaction whose Dart handler did not reply within 30 seconds, or was released because the plugin detached from its engine, resolved with `committed: false` and no error, exactly like a handler that returned `Transaction.abort()`. A debugger pause longer than the timeout silently aborted valid transactions. `runTransaction` now throws a `FirebaseException` instead: code `deadline-exceeded` on timeout (as cloud_firestore does), or `cancelled` when the engine detached first. The failure is recorded on the handler and reported from onComplete, because the RTDB SDK turns an exception thrown from doTransaction into an uncoded "user code" error. Also: - reset the detached state when the plugin is attached again, so a re-attached plugin calls Dart again instead of aborting every transaction; - use a reply that arrives just after the timeout, and only log when the result is really missing; - correct the comment on the timeout, which is reached by debugger pauses, blocked main threads and replies lost during hot restart or detach.
daf3ab6 to
67a1098
Compare
Description
On Android, a transaction blocks the database's thread until the Dart handler replies. If the engine is destroyed while the handler is pending, no reply ever comes, and every later read, write, listener and transaction on that database hangs. This affects every engine in the process, so a background engine (a messaging background handler, for example) torn down mid-transaction freezes the database for the app.
Fix:
FirebaseException(code: 'deadline-exceeded'), as cloud_firestore does;cancelled.A transaction that returns
Transaction.abort()is still reported ascommitted: false, as before.Follow-up: iOS and macOS have the same unbounded wait.
Tests
Android JUnit (
FirebaseDatabasePluginTest, now run byandroid-unit-tests), with a fake messenger that replies only when told to:transaction_failsWithDeadlineExceededWhenDartNeverReplies,detachFromEngine_failsAPendingTransactionandtransaction_failsWithoutCallingDartAfterDetachhang with the old unbounded wait;initPluginInstance_callsDartAgainAfterADetachchecks the plugin works again after it is attached again;transaction_commitsTheValueFromDartandtransaction_abortedByDartCompletesWithoutAnErrorcover the normal paths.Related Issues
None found.
Checklist
///).melos run analyze) does not report any problems on my PR.Breaking Change