Repository navigation
Conversation
…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.
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. |
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.
Description
databaseReferenceRunTransactionruns the Dart transaction handler fromTransaction.Handler.doTransaction, which the RTDB SDK calls on its run-loop thread. The plugin posted the call to the main thread and then blocked that thread on an unboundedCountDownLatch.await()until Dart replied.Nothing replies when the engine is destroyed, or its messenger detached, while the handler is pending: once detached,
FlutterJNI.dispatchPlatformMessagelogs "FlutterJNI was detached from native C++. Could not send." and drops the message, so the reply callback never runs. The run-loop thread then stays blocked, and every later operation on that database instance hangs: reads, writes, listeners and other transactions.FirebaseDatabaseinstances are shared by the process, so a transaction started from a background engine (for example a messaging background handler) that is torn down mid-transaction also freezes the database for the main engine.This PR:
runTransactionthrowsFirebaseException(code: 'deadline-exceeded'). The Dart handler is synchronous, so a live engine replies at once; the timeout is reached when the isolate is paused in a debugger, the main thread is blocked, or the reply is lost (hot restart, detach). 30 seconds and the code match cloud_firestore's transaction timeout on Android (TransactionStreamHandler,semaphore.tryAcquire(timeout)).onDetachedFromEngine, like cloud_firestore releases its semaphore inonCancel, so the database recovers at once rather than after the timeout. That transaction, and any the SDK reruns after the detach (without calling Dart), fail withcancelled.A timed-out or released handler is never reported as
committed: false, which stays reserved for a handler that returnsTransaction.abort(). The failure is recorded on the RTDBTransaction.Handlerand reported fromonComplete: throwing fromdoTransactionwould not work, because the SDK turns the exception intoDatabaseError.USER_CODE_EXCEPTIONwith a stack trace as message, which surfaces in Dart asunknown.The wait lives in
callTransactionHandler, the RTDB handler intransactionHandler(request, callback), and the plugin takes the main-thread executor and the timeout through an internal constructor, so the JUnit tests can drive them. The no-argument constructor used by the plugin registrant is unchanged.Review fixes
deadline-exceeded/cancelled, as above.isDetachedis reset on attach.FlutterPluginBindingreflectively; they call the internalinitPluginInstance/detachFromEnginethatonAttachedToEngine/onDetachedFromEnginedelegate to.Follow-ups (not in this PR)
FLTFirebaseDatabasePlugin.swift:296-318, shared through a symlink) have the same unboundedsemaphore.wait(), onFIRDatabaseQuery.sharedQueue, which is process-wide, anddetachFromEnginedoes not release it.runTransaction,TransactionHandler,TransactionExecutorandtransactionRequestsin the Android plugin are unused; to be removed separately.android_unit_tests.yamlconflicts with fix(messaging,android): deliver every foreground message to onMessage exactly once #18831, fix(storage): keep tasks alive when snapshotEvents listeners cancel, and scope Android task registries per engine #18839 and fix(remote_config): deliver onConfigUpdated errors on Android and iOS as FirebaseException with stable codes #18840, which each add a task to it; whichever lands later needs to keep every task.Tests
New JUnit tests in
FirebaseDatabasePluginTest(android/src/test), now run byandroid-unit-tests(:firebase_database:testDebugUnitTest). They drive the plugin's RTDBTransaction.Handler(doTransaction, thenonComplete, as the SDK does), with the real PigeonFirebaseDatabaseFlutterApion a fakeBinaryMessengerthat only replies when told to, and check what is reported to Dart:isDetachednever reset)transaction_commitsTheValueFromDarttransaction_abortedByDartCompletesWithoutAnErrortransaction_failsWithDeadlineExceededWhenDartNeverRepliescommitted: false)detachFromEngine_failsAPendingTransactiontransaction_failsWithoutCallingDartAfterDetachinitPluginInstance_callsDartAgainAfterADetachWith the original unbounded wait, the timeout and detach cases hang (JUnit 10 s timeout), as measured for the first commit.
Not covered by e2e: destroying an engine while its handler is pending can't be timed reliably from a Dart test.
Related Issues
None found.
Checklist
///).melos run analyze) does not report any problems on my PR.Breaking Change