`No iteration is active` still reachable after #410: `_nonLineSyncEvents` senders are not gated on an active iteration

[xyyyy]

Summary

We see recurring SqliteException(21): powersync_control: invalid state: No iteration is active
on Android, on SDK versions that already contain the control-flow refactor from #410
(we have run 2.1.0, 2.3.0 and 2.3.1).

What we observe

• Android only. Our web build never produced this error.
• Across 13 devices, independent of app build and independent of upload health.
• Correlates with two conditions: access token expiry (we log JWT has expired followed by a burst
  of these errors within ~2s), and network churn (one device logged 3522 network failures over 7 days).
• Usually transient and self-healing within seconds. We have also recorded sustained episodes —
  longest 115 minutes. During those, downloads stop while local writes and uploads keep working,
  so the device stops seeing other devices' changes.
• disconnect() + connect() does not recover it. One device logged 92 reconnects over 2 hours
  with lastSyncedAt frozen throughout. A full process restart does recover it.

What we found in the source

In powersync-sqlite-core (crates/core/src/sync/streaming_sync.rs) the core moves itself to
ClientState::Idle both on any error returned from handle.run() and on normal completion —
run() returns done = true in the same invocation in which it pushes Instruction::CloseSyncStream.
Any subsequent SyncEvent then produces this error. Same in core v0.4.13 and v0.5.x.

In the Dart client, two senders push into sync._nonLineSyncEvents — a broadcast controller owned by
StreamingSyncImplementation, so it outlives individual iterations — guarded only by !sync.aborted:

• packages/powersync/lib/src/sync/streaming_sync.dart (2.3.1, ~L264): _uploadAllCrud().whenComplete
  adds UploadCompleted. The CRUD loop runs concurrently with iterations and is driven by local writes.
• same file, ~L581: FetchCredentials(didExpire: false) starts a fire-and-forget
  prefetchCredentials().then((_) { if (!sync.aborted) _nonLineSyncEvents.add(TokenRefreshComplete()); }),
  whose resolution time depends on the network.

Environment

• powersync 2.1.0 / 2.3.0 / 2.3.1 (Flutter), core extension v0.4.13
• Flutter 3.41.9 (Dart 3.11.5), Android, Samsung SM-T500 tablets and similar
• Backend: Supabase Postgres + PowerSync Cloud

[simolus3]

In the Dart client, two senders push into sync._nonLineSyncEvents — a broadcast controller owned by
StreamingSyncImplementation, so it outlives individual iterations — guarded only by !sync.aborted:

I doubt this is the problem: If we're not currently in a _handleLines iteration, there is nothing listening on that broadcast stream that might forward these events to the core extension. Broadcast streams also don't buffer events when there's no listener, so adding stray events after the sync iteration completes is a no-op.

We also break out of _handleLines after errors and on a CloseSyncStream instruction, so that matches what the core extension expects.

[xyyyy]

Fair enough, our logs agree that those two _nonLineSyncEvents senders are not where this mostly comes from.

We log the full SqliteException text, and it carries the powersync_control operation that failed. Over 2026-06-09 to 2026-08-03, 2195 occurrences across 38 Android devices:

operation	occurrences	devices	last seen
line_binary	1941	38	2026-08-03
connection	181	10	2026-08-03
completed_upload	68	8	2026-07-17
(not parsed)	5	4	2026-08-01

[simolus3]

Do you have a way to correlate this with the PowerSync SDK version used by any chance? I want to make sure these aren't just instances of users still on older versions of your app.

[xyyyy]

Sticking only to what I can confirm from telemetry that reported the running version before the error:

powersync 2.3.1: 3 devices, 24 occurrences, most recent 2026-08-03.

Nothing on 2.3.3. We have only just started testing that build. It is on four Android tablets in a single location, so there is no meaningful exposure yet.

For the remaining devices I cannot pin the version at the time of the error with certainty, so I am leaving them out.

For context on the range we run: the oldest powersync still live in our fleet is 2.1.0, on 41 Android tablets. Updates are not forced, so the fleet spans 2.1.0 to 2.3.3.

One question. Which Dart SDK version should this be fixed in on Android? The only shipped fix I can find for this error message is on the JS side, in @powersync/common 1.53.1, and I see no equivalent entry in the powersync.dart changelog up to and including 2.3.4.

[xyyyy]

A new, harder variant of this issue on our fleet (the previously reported "No iteration is active" was always transient).

Device: Samsung SM-T500 (Android), powersync Flutter 2.3.3 / core v0.5.1, self-updated the same day from 2.3.1 / core v0.4.13. Local database ~500 MB. Upload queue (ps_crud) empty.

Timeline (UTC, 2026-08-03):

13:07: app updates to the 2.3.3 build; sync works normally afterwards.
15:29:12: last successful sync; shortly after, the app process ends without any crash being reported.
16:32:16: cold start. Connect succeeds, then the first received sync line fails:

SqliteException(1): while selecting from statement, powersync_control: internal SQLite call returned ERROR, SQL logic error (code 1)
Causing statement: SELECT CAST(powersync_control(?, ?) AS TEXT), parameters: line_binary, blob (55 bytes)
The failure repeats on every reconnect (every occurrence we inspected is line_binary with a 55-byte blob) and survived a second full app restart at 17:51, failing again about 1 second after connecting. lastSyncedAt remains frozen at 15:29:12; nothing has downloaded since.
Service logs for this client: Sync stream started, then New checkpoint (3 buckets), then Sync stream complete with close_reason: "client closing stream", stream_ms: 72, operations_synced: 0, HTTP 200. No service-side errors.

A second device syncing the same buckets, also on 2.3.3/core 0.5.1, is unaffected; it hit a transient "No iteration is active" (code 21) the same day and recovered on its own. Across our fleet on earlier SDK versions, powersync_control failures were always transient (recovered spontaneously or after an app restart); this is our first case that survives restarts.

Is there a supported way to recover a local database from this state, short of disconnectAndClear()?

[simolus3]

For context on the range we run: the oldest powersync still live in our fleet is 2.1.0, on 41 Android tablets. Updates are not forced, so the fleet spans 2.1.0 to 2.3.3.

That version already has the fix, it was part of version 2.0.2. So this confirms that the issue is still present :/

powersync_control: internal SQLite call returned ERROR, SQL logic error (code 1)

This also shouldn't happen, and it's really bad that we can't recover. Without us knowing the root cause, I can't think of a recovery strategy apart from disconnectAndClear() unfortunately. I'll at least take a look at improving the error message here to provide more information about what the issue is.

[xyyyy]

Still stuck ~23 hours later, same device, no recovery.

From the first failure (2026-08-03 16:32:16 UTC) to 2026-08-04 14:47:48 UTC: 1754 line_binary failures across 6 cold starts of the app. lastSyncedAt still frozen at 2026-08-03 15:29:12 UTC. Upload queue still empty.

A second, different error appeared on the same device 46 minutes after the first line_binary failure, and is still occurring. Plain reads against a PowerSync view fail:

SqliteException(1): while selecting from statement, malformed JSON, SQL logic error (code 1)
Causing statement: SELECT customer_id, COUNT(*) AS cnt FROM appointments
WHERE no_show = 1 AND archived_at IS NULL AND customer_id IS NOT NULL GROUP BY customer_id
6 occurrences, first 2026-08-03 17:18:01 UTC, most recent 2026-08-04 13:07:11 UTC. No other device in our fleet has produced this error, on any SDK version.

Version correlation for this exact device, since you asked about that earlier: on core v0.4.13 it produced line_binary failures on 2026-07-17 (3 occurrences within 44 s), 2026-07-20 (3) and 2026-07-28 (2 within 2 s). Every episode cleared on its own. Same hardware, same app apart from the SDK upgrade.

We have not run disconnectAndClear() yet. If you want anything read out of the database first, tell us what to capture and we will run it.

We are also moving this device back to 2.3.1 / core v0.4.13 and can report whether the automatic down-migration clears the state.

[simolus3]

If you want anything read out of the database first, tell us what to capture and we will run it.

Is it possible for you to obtain a full copy of the database file (and -wal file if possible)? You might have to remove sensitive information in there before sending it to us (we can follow up on that), but these errors are likely deterministic. So if you have a copy of the file, we can also send you test scripts to run on it to investigate.