fix(database): recover from Room's silent connection-pool wedge (#6608) by jamesarich · Pull Request #6658 · meshtastic/Meshtastic-Android

jamesarich · 2026-08-12T19:08:06Z

Why

Field reports in #6608 describe a permanent wedge on 2.8.1-SNAPSHOT: the node list empties and never reloads, updates stop, and only a force-stop recovers. The attached logcats pinned it to a leaked permit in Room 3.0.1's ConnectionPoolImpl — but reading them closely changes the diagnosis in a way that matters:

W/System.err: android.database.SQLException: Error code: 5, message: Timed out attempting to acquire a reader connection.
  Request coroutine: [..., DispatchedCoroutine{Cancelling}@667fccf, Dispatchers.IO.limitedParallelism(1)]
  Writer pool: Pool@b1ce8e7 (capacity=1, permits=0, queue=(size=0)[])
    [1] - BundledSQLiteConnection@3efbc94   Status: Free connection
  at androidx.room3.coroutines.ConnectionPoolImpl.onTimeout(ConnectionPoolImpl.kt:196)
  at androidx.room3.coroutines.Pool.acquireWithTimeout-KLykuaI(ConnectionPoolImpl.kt:242)

That is W/System.err — a printStackTrace() from Room's LOG_TIMEOUT_EXCEPTION mode, not an exception delivered to us. Across the three logs there are 156 dumps in a single second and zero app-side recovery log lines. Room's acquireWithTimeout logs the timeout and loops forever, so a wedged pool produces neither a value nor a failure: every DAO flow simply hangs.

Everything we had built for this failure keyed off a thrown SQLException, so none of it could ever fire — the recovery caps in DatabaseManager were a red herring, not the cause. On top of that, NodeRepositoryImpl.nodeDBbyNum is stateIn(processLifecycle, SharingStarted.Eagerly, …); once its upstream terminates, the sharing coroutine is dead for the process and re-navigation cannot restart it. That is the "node list disappears and never reloads" symptom.

setSingleConnectionPool() and the limitedParallelism(1) query context are unchanged — both remain load-bearing (see the configureCommon KDoc).

🐛 Fixes

Detect the silent stall. observeCurrentDb now bounds the first emission of each re-latched DAO flow (45s, comfortably above any legitimate cold-open/migration/backfill-contended query, and above Room's own 30s acquire timeout). A missing first emission raises DbFlowStalledException, which routes into the existing pool-reopen recovery. Only the first emission per latch is bounded — later emissions are event-driven and legitimately sparse.
Keep recovery available for the life of the process. MAX_FLOW_POOL_RECOVERIES_PER_MANAGER_LIFETIME became MAX_FLOW_POOL_RECOVERIES_PER_WINDOW over a sliding 10-minute window. Reporters see wedges "multiple times within minutes", which exhausted the old lifetime budget and made every later wedge permanent by construction.
Restart eagerly-shared repository flows. retryOnDbPoolFailure restarts a database-backed flow after a recoverable pool failure with capped exponential backoff (reset on a successful emission; non-database failures still propagate). Applied to every observeCurrentDb call site, so a terminal failure can no longer kill a process-lifetime SharingStarted.Eagerly StateFlow.

🧹 Cleanups

RadioConfigRepositoryImplTest builds SwitchingChannelSetDataSource with the real FakeDatabaseProvider instead of a mokkery autofill mock, which returns null for the non-null DAO flow.

Known remaining gap (not fixed here)

The one-shot write path has the same exposure and is not addressed: withDb runs its callback under NonCancellable on dispatchers.io.limitedParallelism(1), so a callback wedged inside Room can neither be cancelled nor timed out, and every later withDb queues behind it forever. Reopening the pool does not help because the lane never drains. That is the likely cause of the "disconnect impossible" half of #6608 and needs its own design — a bounded-wait scheme or a per-pool lane — rather than a timeout that cannot interrupt a NonCancellable block.

The TAK-server/session-lease backpressure wedge that drives the cancellation churn is being handled on a separate track.

Testing Performed

Baseline gate green: spotlessApply spotlessCheck detekt assembleDebug test allTests kmpSmokeCompile.

New tests:

DatabaseManagerShutdownTest.silentlyStalledFlowIsRecoveredWithoutAnyThrownFailure — a DAO flow that never emits and never fails (exactly what a leaked permit looks like) is recovered.
…quietFlowAfterAFirstEmissionIsNotTreatedAsStalled — a flow that emits once then stays quiet for 3× the deadline does not trigger recovery.
…flowPoolRecoveryResumesAfterTheRateWindowClears — the [Bug]: Stale node connection still occurring after fix for #6491 #6608 regression: after the budget is spent, a later wedge still recovers once the window clears.
…recurringFlowPoolRecoveryNeverClosesDetachedPoolsBeforeShutdown — recovery retains every replaced pool and only close() reclaims them.
DbFlowRecoveryTest — restart on acquire-timeout and closed-pool failures, propagation of unrelated failures, backoff reset after a successful emission.
PoisonedPoolNodeFlowRecoveryTest — poisons the pool for far more failures than any recovery budget allows and proves nodeDBbyNumFlow, myNodeInfoFlow, and an eagerly-shared StateFlow over them still reach a value.

Rebased onto #6661 — and this changes one policy it just shipped

#6661 landed first and rewrote withDb, so this is rebased onto it. Its hasReachedRecoveryLimit(origin) / recordRecovery(origin) seam is kept and my sliding window moved inside it, which is cleaner than either branch alone.

The policy change, stated plainly: #6661 bounded wedge recovery with MAX_WEDGE_POOL_RECOVERIES_PER_MANAGER_LIFETIME = 3 and quarantined the pool once spent. That is the same lifetime-budget shape this PR removes for the Flow path, and it has the same consequence. The quarantine clears in only three places — closeInactiveDatabase, the reopen-replacement path, and close(). The quarantined pool is _currentDb, so it is never an inactive eviction candidate, and the reopen path is exactly what a spent budget refuses. So after three wedges in one process, writes fail fast until a device switch or a force-stop. Given #6608 reporters see wedges recurring within minutes, three arrives quickly.

Both budgets are now one sliding window (POOL_RECOVERY_WINDOW_MS), with per-origin deques and per-origin limits (6 Flow, 3 wedge). Per-origin so a Flow-recovery storm cannot starve the write path's budget; limits kept distinct so #6661's chosen sensitivity is preserved rather than silently re-tuned.

Quarantine expiry is the load-bearing half. Windowing the budget alone would change nothing observable: recovery is refused until a write is admitted, and writes are refused until recovery happens. The quarantine therefore expires with the same window. It is evaluated in the quarantine map rather than against the budget deques because the gate holds writerTrackerMutex while the deques are guarded by mutex, and the established order is mutex → writerTrackerMutex; reading the budget there would invert it.

Expiry re-admits against the still-wedged pool, since nothing replaced it — so the first write back pays one WITH_DB_TIMEOUT_MS deadline and its abandonment publishes the replacement. That sacrificial write is the guaranteed floor; when DAO Flows are collecting, a stall recovery usually replaces the pool sooner. writesRecoverAfterTheWedgeWindowClears pins the whole cycle rather than stopping at re-admission, which would pass even if recovery never completed.

History: the CMP 1.12.0-rc01 detour

Earlier revisions of this description reported main as red and attributed CI failures across three theories. Final resolution: the failures were regressions from the CMP 1.12.0-rc01 bump (#6662), which merged with its test shards cancelled and was masked afterwards by build-cache replay. It was reverted in #6664, and this branch is rebased onto that revert (d8361ccd1). The full attribution trail — including two incorrect attributions by this PR's author, and their corrections — is preserved in the comments.

The one known residual flake repo-wide is NodeDetailCompassLifecycleTest (~66% per run, CMP-independent, waitUntil timeout); if this PR merges only after a retry that flipped it, the merge report will say so.

Review follow-up

CodeRabbit caught a real defect in the first push: I had added trimming of detached (replaced) pools to bound memory, gated on the reader/writer access counters. Those counters only cover withReadDb/withDb. DAO Flow collectors are untracked, and Paging factories latch a raw currentDb.value — PacketRepositoryImpl.kt:69 builds its paging source that way — so trimming could close a pool a live PagingSource still held and surface Connection pool is closed. That would have traded a recoverable wedge for a new crash.

Trimming is removed; the documented invariant (only close() reclaims detached pools) is restored, and the recovery rate window is what bounds churn. The trade-off is explicit: under a repeated wedge, replaced pools accumulate until shutdown, capped in rate rather than in total. Correctness over memory — an idle detached pool costs one SQLite connection and a statement cache, while closing one out from under a Paging source breaks the message list.

One pre-existing test (flowPoolRecoveryStopsAfterIntermittentFailuresFillTheRateWindow) caught a real defect in the first draft of this change: the recovery counter reset sat downstream of the new channel hop, where an upstream failure can overtake the value emitted a moment earlier. The reset now runs in the producing coroutine.

Not validated on a device — the wedge is a timing-dependent field failure we have not reproduced locally.

Upstream draft — Google Issue Tracker filing for the Room bug (for James to file; not submitted)

Google Issue Tracker draft — DO NOT FILE AUTOMATICALLY

Component: Android Public Tracker > Android Public Tracker > Jetpack (androidx) > Room
Type: Bug · Version: androidx.room3 3.0.1 (also present in 3.0.0)
Title: ConnectionPoolImpl leaks a connection permit when an acquire times out after acquire() already
succeeded, permanently wedging the pool (permits=0 with all connections Free)

Summary

Pool.acquireWithTimeout can drop a successfully acquired ConnectionWrapper without recycling it, losing the
semaphore permit that the acquisition consumed. With setSingleConnectionPool() (capacity = 1) the pool becomes
permanently unusable: every subsequent useConnection waits the full 30s timeout, and because the pool's default
onTimeout mode is LOG_TIMEOUT_EXCEPTION, acquireWithTimeout's while (true) loop retries forever. The
application sees neither a value nor an exception — every database read hangs for the life of the process, while
logcat fills with the acquire-timeout dump.

We are hitting this in production in Meshtastic-Android (KMP, BundledSQLiteDriver, Android + JVM desktop). Field
reports describe a permanent app wedge that only a force-stop clears.

Analysis

ConnectionPoolImpl.kt (3.0.1), Pool.acquireWithTimeout:

suspend fun acquireWithTimeout(timeout: Duration, onTimeout: () -> Unit): ConnectionWrapper {
    while (true) {
        var connection: ConnectionWrapper? = null
        var exceptionThrown: Throwable? = null
        try {
            withTimeout(timeout) { connection = acquire() }   // (1) permit consumed inside acquire()
        } catch (ex: Throwable) {
            exceptionThrown = ex
        }
        try {
            if (exceptionThrown is TimeoutCancellationException) {
                onTimeout.invoke()                            // (2) only LOGS in the default mode
            } else if (exceptionThrown != null) {
                throw exceptionThrown
            } else if (connection != null) {
                return connection
            }
        } catch (ex: Throwable) {
            connection?.let { recycle(it) }                   // (3) the ONLY recycle-on-failure path
            throw ex
        }
    }
}

The defect is the interaction of (1), (2) and (3):

acquire() consumes a permit from connectionPermits and returns a wrapper. The assignment to the outer
connection var therefore happens before withTimeout returns.
withTimeout still throws TimeoutCancellationException if its deadline elapses as the block completes. The
result is exceptionThrown is TimeoutCancellationException and connection != null.
In that state, branch (2) runs. onTimeout is ConnectionPoolImpl.onTimeout, whose behavior depends on the
internal var onTimeout mode. The default is LOG_TIMEOUT_EXCEPTION, which calls
ex.printStackTrace() and returns normally.
Because nothing throws, the catch at (3) — the only place a stranded connection is recycled — never runs.
The loop iterates, connection is re-initialized to null, and the acquired wrapper is unreachable. Its permit
is never released.

Only THROW_TIMEOUT_EXCEPTION mode is safe here, and that mode is not publicly configurable
(see the TODO(b/404380974) above internal var timeout).

Two consequences:

Permit leak. capacity = 1 (single-connection pool) means one leak wedges the pool forever. A multi-reader
pool degrades one permit at a time toward the same end state.
The wedge is invisible to application code. In LOG_TIMEOUT_EXCEPTION mode acquireWithTimeout never
returns and never throws, so useConnection — and every DAO query/Flow above it — hangs indefinitely. An app
cannot detect or recover from this through normal error handling; it can only infer it from a missing result.

Cancellation churn makes the race reachable in practice: our DB flows are re-latched via flatMapLatest on device
switches, so acquisitions are routinely cancelled mid-flight (the dumps below show the requesting coroutine in
Cancelling state).

Evidence (production logcat, Meshtastic-Android 2.8.1)

W/System.err: android.database.SQLException: Error code: 5, message: Timed out attempting to acquire a reader connection.

Request coroutine: [..., DispatchedCoroutine{Cancelling}@667fccf, Dispatchers.IO.limitedParallelism(1)]

Writer pool:
	androidx.room3.coroutines.Pool@b1ce8e7 (capacity=1, permits=0, queue=(size=0)[])
		[1] - androidx.sqlite.driver.bundled.BundledSQLiteConnection@3efbc94
		Status: Free connection
		Prepared Statement Cache Size: 25
Reader pool:
	androidx.room3.coroutines.Pool@b1ce8e7 (capacity=1, permits=0, queue=(size=0)[])
		[1] - androidx.sqlite.driver.bundled.BundledSQLiteConnection@3efbc94
		Status: Free connection
		Prepared Statement Cache Size: 25
	at androidx.sqlite.SQLite__SQLiteKt.throwSQLiteException(SQLite.kt:64)
	at androidx.room3.coroutines.ConnectionPoolImpl.onTimeout(ConnectionPoolImpl.kt:196)
	at androidx.room3.coroutines.ConnectionPoolImpl.useConnection$lambda$0(ConnectionPoolImpl.kt:156)
	at androidx.room3.coroutines.Pool.acquireWithTimeout-KLykuaI(ConnectionPoolImpl.kt:242)

The dump is self-consistent with the analysis and, as far as we can tell, with nothing else:

permits=0 — the single permit is gone.
queue=(size=0)[] — the connection is not in availableConnections, so recycle() was never called for it.
Status: Free connection — ConnectionWrapper.dump prints this only when acquireCoroutineContext == null.
markAcquired(...) is applied in useConnection after acquireWithTimeout returns, so a wrapper that was
acquired inside acquire() but dropped by the timeout branch is exactly one that shows Free while its permit is
held. A connection genuinely in use would print Coroutine: [...] instead.
W/System.err with the frame ConnectionPoolImpl.onTimeout reached from Pool.acquireWithTimeout confirms
LOG_TIMEOUT_EXCEPTION (printStackTrace), i.e. the exception is never delivered to the caller.
156 such dumps within the same second, and zero across three field logs are followed by any recovery: every
waiter in the app is parked on the wedged pool.

Once wedged, the state never clears — reported repeatedly, and only force-stopping the app restores function.

Suggested fix

In Pool.acquireWithTimeout, recycle an acquired connection whenever the iteration is not going to return it,
independently of whether onTimeout throws:

if (exceptionThrown is TimeoutCancellationException) {
    val stranded = connection
    connection = null
    stranded?.let { recycle(it) }   // release the permit before retrying/logging
    onTimeout.invoke()
}

Equivalently: move the recycle into a finally that runs unless the wrapper is being returned.

Secondary requests:

Make onTimeout / timeout publicly configurable (b/404380974). LOG_TIMEOUT_EXCEPTION turns a pool-level
fault into an unbounded silent hang, which application code cannot recover from. At minimum, consider making
THROW_TIMEOUT_EXCEPTION the default, or bounding the while (true) retry loop.
Consider asserting the invariant permits == capacity when every connection is Free, so a leaked permit is
surfaced as a diagnosable error rather than an infinite wait.

Environment

androidx.room3 3.0.1, androidx.sqlite BundledSQLiteDriver
Kotlin Multiplatform: Android (minSdk 26) and JVM desktop; both platforms reproduce the wedge in the field
Pool configured with setSingleConnectionPool() and
setQueryCoroutineContext(ioDispatcher.limitedParallelism(1))
Long-lived DAO Flows re-latched with flatMapLatest on database switches (the cancellation churn)

Notes for James before filing

Attach the three field logcats from [Bug]: Stale node connection still occurring after fix for #6491 #6608 (user-attachments 30935731 / 30935732 /
30935733). 30935732 downloaded as a 9-byte file for me — re-fetch it from the issue before attaching.
We have not reproduced this in an isolated harness; the analysis is from the 3.0.1 sources plus the field dumps.
If the Room team asks for a repro, the shape to try is: capacity = 1 pool, a coroutine that cancels acquisitions
in a tight loop, and timeout reduced so the withTimeout-completes-as-deadline-elapses window is hit often.

coderabbitai · 2026-08-12T19:08:16Z

📝 Walkthrough

Walkthrough

The change adds database-flow retry handling, stalled-flow detection, sliding-window recovery limits, detached-pool cleanup, and regression tests. Data-source flows now use the retry operator for recoverable Room pool failures.

Changes

Database flow recovery

Layer / File(s)	Summary
Flow retry operator `core/database/src/commonMain/kotlin/org/meshtastic/core/database/DbFlowRecovery.kt`, `core/database/src/commonTest/kotlin/org/meshtastic/core/database/DbFlowRecoveryTest.kt`	Adds `retryOnDbPoolFailure` with recoverable-error filtering, capped backoff, retry logging, and reset-after-emission behavior. Tests cover timeout, closed-pool, unrelated failures, and backoff reset.
Database manager recovery `core/database/src/commonMain/kotlin/org/meshtastic/core/database/DatabaseManager.kt`, `core/database/src/commonTest/kotlin/org/meshtastic/core/database/DatabaseManagerShutdownTest.kt`, `core/database/src/commonTest/kotlin/org/meshtastic/core/database/DatabaseManagerTestFixture.kt`	`DatabaseManager` detects stalled initial emissions, applies sliding-window recovery limits, retains and trims detached pools, and exposes a test clock. Tests cover stalled flows, recovery-window expiry, and pool retention.
Data-source integration `core/data/src/commonMain/kotlin/org/meshtastic/core/data/datasource/*DataSource.kt`, `core/data/src/commonMain/kotlin/org/meshtastic/core/data/repository/NodeRepositoryImpl.kt`, `core/data/src/commonTest/kotlin/org/meshtastic/core/data/datasource/PoisonedPoolNodeFlowRecoveryTest.kt`, `core/data/src/commonTest/kotlin/org/meshtastic/core/data/repository/RadioConfigRepositoryImplTest.kt`	Data-source flows retry recoverable database-pool failures. Node-flow regression tests cover repeated acquisition failures, and radio configuration tests use `FakeDatabaseProvider` cleanup.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
  participant DataSource
  participant DatabaseManager
  participant DatabasePool
  DataSource->>DatabaseManager: observe current database flow
  DatabaseManager->>DatabasePool: acquire pool and collect query
  DatabasePool-->>DatabaseManager: emit data or pool failure
  DatabaseManager->>DatabasePool: relatch replacement pool after recovery
  DatabaseManager-->>DataSource: publish recovered flow value

Possibly related PRs

meshtastic/Meshtastic-Android#6540: Extends the database-observer recovery mechanism used by the same data-source flows and DatabaseManager.

Suggested reviewers: jeremiah-k

🚥 Pre-merge checks | ✅ 6

✅ Passed checks (6 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Sibling Call Sites And Presence Semantics	✅ Passed	The diff changes database-flow recovery only; it adds no nullable or presence semantics for telemetry fields and no physical-metric default of 0. NodeItem and NodeItemCompact are unchanged.
Tests Prove The Path, Not The End State	✅ Passed	Added recovery tests inject failures and assert retries, attempts, pool replacement, retention, and exact emissions; no new fake-store seed check or Unconfined order assertion. Size-only Radio asse...
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: recovering from Room connection-pool wedges that silently stall database flows.

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

Create stacked PR
Commit on current branch

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

codecov · 2026-08-12T19:22:05Z

❌ 11 Tests Failed:

Tests completed	Failed	Passed	Skipped
6039	11	6028	0

View the top 2 failed test(s) by shortest run time

org.meshtastic.feature.settings.radio.RadioConfigViewModelTest::updateChannels serializes overlapping channel saves()[jvm]

Stack Traces | 0.028s run time

kotlinx.coroutines.CompletionHandlerException: Exception in completion handler ResumeAwaitOnCompletion@25304ab7[job@6df5db6d] for "coroutine#1433":DeferredCoroutine{Completed}@6df5db6d
	at kotlinx.coroutines.JobSupport.completeStateFinalization(JobSupport.kt:313)
	at kotlinx.coroutines.JobSupport.tryFinalizeSimpleState(JobSupport.kt:288)
	at kotlinx.coroutines.JobSupport.tryMakeCompleting(JobSupport.kt:887)
	at kotlinx.coroutines.JobSupport.makeCompletingOnce$kotlinx_coroutines_core(JobSupport.kt:859)
	at kotlinx.coroutines.AbstractCoroutine.resumeWith(AbstractCoroutine.kt:99)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:47)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:100)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:586)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:807)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:717)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:704)
Caused by: kotlinx.coroutines.DispatchException: Coroutine dispatcher Dispatchers.Main threw an exception, context = [CoroutineId(1431), "coroutine#1431":StandaloneCoroutine{Active}@4f2569af, Dispatchers.Main]
	at kotlinx.coroutines.internal.DispatchedContinuationKt.safeIsDispatchNeeded(DispatchedContinuation.kt:264)
	at kotlinx.coroutines.DispatchedTaskKt.dispatch(DispatchedTask.kt:144)
	at kotlinx.coroutines.CancellableContinuationImpl.dispatchResume(CancellableContinuationImpl.kt:470)
	at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl$kotlinx_coroutines_core(CancellableContinuationImpl.kt:504)
	at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl$kotlinx_coroutines_core$default(CancellableContinuationImpl.kt:493)
	at kotlinx.coroutines.CancellableContinuationImpl.resumeWith(CancellableContinuationImpl.kt:359)
	at kotlinx.coroutines.ResumeAwaitOnCompletion.invoke(JobSupport.kt:1557)
	at kotlinx.coroutines.JobSupport.completeStateFinalization(JobSupport.kt:311)
	... 10 more
Caused by: java.lang.IllegalStateException: Dispatchers.Main was accessed when the platform dispatcher was absent and the test dispatcher was unset. Please make sure that Dispatchers.setMain() is called before accessing Dispatchers.Main and that Dispatchers.Main is not accessed after Dispatchers.resetMain().
	at kotlinx.coroutines.test.internal.TestMainDispatcherJvmKt.reportMissingMainCoroutineDispatcher(TestMainDispatcherJvm.kt:45)
	at kotlinx.coroutines.test.internal.TestMainDispatcherJvmKt.access$reportMissingMainCoroutineDispatcher(TestMainDispatcherJvm.kt:1)
	at kotlinx.coroutines.test.internal.TestMainDispatcherFactory.createDispatcher$lambda$2(TestMainDispatcherJvm.kt:20)
	at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:86)
	at kotlinx.coroutines.test.internal.TestMainDispatcher.getMainDispatcher(TestMainDispatcher.kt:18)
	at kotlinx.coroutines.test.internal.TestMainDispatcher.getDispatcher(TestMainDispatcher.kt:22)
	at kotlinx.coroutines.test.internal.TestMainDispatcher.isDispatchNeeded(TestMainDispatcher.kt:32)
	at kotlinx.coroutines.internal.DispatchedContinuationKt.safeIsDispatchNeeded(DispatchedContinuation.kt:262)
	... 17 more
Caused by: java.lang.IllegalStateException: Module with the Main dispatcher is missing. Add dependency providing the Main dispatcher, e.g. 'kotlinx-coroutines-android' and ensure it has the same version as 'kotlinx-coroutines-core'
	at kotlinx.coroutines.internal.MainDispatchersKt.throwMissingMainDispatcherException(MainDispatchers.kt:77)
	at kotlinx.coroutines.internal.MissingMainCoroutineDispatcher.missing(MainDispatchers.kt:108)
	at kotlinx.coroutines.internal.MissingMainCoroutineDispatcher.dispatch(MainDispatchers.kt:101)
	at kotlinx.coroutines.internal.MissingMainCoroutineDispatcher.dispatch(MainDispatchers.kt:84)
	at kotlinx.coroutines.test.internal.TestMainDispatcherFactory.createDispatcher$lambda$2(TestMainDispatcherJvm.kt:22)
	... 22 more

org.meshtastic.core.ui.viewmodel.ConnectionsViewModelTest::connected older known node exposes Android firmware update notice()[jvm]

Stack Traces | 0.105s run time

org.opentest4j.AssertionFailedError: expected: <1> but was: <0>
	at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1210)
	at kotlin.test.junit5.JUnit5Asserter.assertEquals(JUnitSupport.kt:32)
	at kotlin.test.AssertionsKt__AssertionsKt.assertEquals(Assertions.kt:63)
	at kotlin.test.AssertionsKt.assertEquals(Unknown Source)
	at kotlin.test.AssertionsKt__AssertionsKt.assertEquals$default(Assertions.kt:62)
	at kotlin.test.AssertionsKt.assertEquals$default(Unknown Source)
	at org.meshtastic.core.ui.viewmodel.ConnectionsViewModelTest$connected older known node exposes Android firmware update notice$1.invokeSuspend(ConnectionsViewModelTest.kt:201)
	at org.meshtastic.core.ui.viewmodel.ConnectionsViewModelTest$connected older known node exposes Android firmware update notice$1.invoke(ConnectionsViewModelTest.kt)
	at org.meshtastic.core.ui.viewmodel.ConnectionsViewModelTest$connected older known node exposes Android firmware update notice$1.invoke(ConnectionsViewModelTest.kt)
	at kotlinx.coroutines.test.TestBuildersKt__TestBuildersKt$runTest$2$1$1.invokeSuspend(TestBuilders.kt:317)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:34)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:100)
	at kotlinx.coroutines.test.TestDispatcher.processEvent$kotlinx_coroutines_test(TestDispatcher.kt:24)
	at kotlinx.coroutines.test.TestCoroutineScheduler.tryRunNextTaskUnless$kotlinx_coroutines_test(TestCoroutineScheduler.kt:98)
	at kotlinx.coroutines.test.TestBuildersKt__TestBuildersKt$runTest$2$1$workRunner$1.invokeSuspend(TestBuilders.kt:326)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:34)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:100)
	at kotlinx.coroutines.EventLoopImplBase.processNextEvent(EventLoop.common.kt:256)
	at kotlinx.coroutines.BlockingCoroutine.joinBlocking(Builders.kt:54)
	at kotlinx.coroutines.BuildersKt__BuildersKt.runBlockingImpl(Builders.kt:30)
	at kotlinx.coroutines.BuildersKt.runBlockingImpl(Unknown Source)
	at kotlinx.coroutines.BuildersKt__Builders_concurrentKt.runBlockingK(Builders.concurrent.kt:172)
	at kotlinx.coroutines.BuildersKt.runBlockingK(Unknown Source)
	at kotlinx.coroutines.BuildersKt__Builders_concurrentKt.runBlockingK$default(Builders.concurrent.kt:157)
	at kotlinx.coroutines.BuildersKt.runBlockingK$default(Unknown Source)
	at kotlinx.coroutines.test.TestBuildersJvmKt.createTestResult(TestBuildersJvm.kt:10)
	at kotlinx.coroutines.test.TestBuildersKt__TestBuildersKt.runTest-8Mi8wO0(TestBuilders.kt:309)
	at kotlinx.coroutines.test.TestBuildersKt.runTest-8Mi8wO0(TestBuilders.kt:1)
	at kotlinx.coroutines.test.TestBuildersKt__TestBuildersKt.runTest-8Mi8wO0(TestBuilders.kt:167)
	at kotlinx.coroutines.test.TestBuildersKt.runTest-8Mi8wO0(TestBuilders.kt:1)
	at kotlinx.coroutines.test.TestBuildersKt__TestBuildersKt.runTest-8Mi8wO0$default(TestBuilders.kt:159)
	at kotlinx.coroutines.test.TestBuildersKt.runTest-8Mi8wO0$default(TestBuilders.kt:1)
	at org.meshtastic.core.ui.viewmodel.ConnectionsViewModelTest.connected older known node exposes Android firmware update notice(ConnectionsViewModelTest.kt:179)

View the full list of 9 ❄️ flaky test(s)

org.meshtastic.core.service.MeshNotificationManagerImplConversationTest::notification ids are namespaced per type so a node num cannot clobber the service notification