Fix read-pool lease leak that deadlocks updateSchema (#356)

[marioortizmanero]

What

ReadPool's connection-lease handoff channel (available) lacked an onUndeliveredElement handler. When a read {} (or the withAllConnections acquisition loop) is cancelled during the channel rendezvous — after a worker sends (connection, done) but before the receiver delivers it into its try/finally — the element is silently dropped. done.complete(Unit) is never called, so that worker parks in done.await() forever and the connection is permanently lost from the pool.

Once any lease leaks, ReadPool.withAllConnections { repeat(size) { available.receive() } } can never acquire all connections and hangs forever. updateSchema() reaches the pool through exactly this path:

PowerSyncDatabaseImpl.updateSchema
  → mutex.withLock
    → InternalDatabaseImpl.updateSchema
      → InternalConnectionPool.withAllConnections
        → ReadPool.withAllConnections → repeat(size){ available.receive() }

so a single leaked read lease wedges updateSchema indefinitely while it holds the database mutex.

Why #356 looked schema-related

It isn't about passing the same Schema instance or about connect(). The reporter's app calls updateSchema on cold start while concurrent watch() queries are being cancelled (auth churn over a dead/slow network) — that cancellation is what leaks the lease. A standalone updateSchema with no concurrent reads (the minimal repro) never leaks, which is why it passed.

Fix

Add onUndeliveredElement to the available channel:

onUndeliveredElement = { (_, done) -> done.complete(Unit) }

onUndeliveredElement fires exactly when an element was handed to the channel but not received (cancelled receiver, or close()/cancel() with an in-flight element). Completing done returns the connection to circulation. CompletableDeferred.complete() is idempotent and non-suspending, so there's no double-completion hazard with the normal finally paths. This covers both leak windows — read() and the withAllConnections add(receive()) gap — and the close path.

How we found this

A thread dump was useless — every thread was idle/parked with no SQLite or native frame (a suspended-coroutine deadlock, not a blocked thread). Coroutine debug probes are inert on Android/ART, so we reflected into the live pool from a debug build at the moment of the hang: all 5 read workers alive, DB mutex held, writeLockMutex still free, but one connection checked out and never returned — i.e. withAllConnections stuck on its final available.receive() after a leaked read lease. That pointed straight at ReadPool and the missing onUndeliveredElement.

Test

ReadPoolLeaseLeakTest hammers the read pool with concurrent reads cancelled at varied points, then asserts updateSchema completes under a timeout. It runs on real dispatchers (the race is hidden by the virtual-time test dispatcher).

• Before the fix: fails with TimeoutCancellationException from updateSchema.
• After the fix: passes in a few ms.

Full :common:jvmTest suite: 130 tests, 0 failures.

Fixes #356.

[simolus3]

Good catch, thanks for the fix!