mirror of
https://github.com/stablyai/orca.git
synced 2026-09-28 00:02:41 +00:00
* perf(mobile): coalesce stalled connection log persistence * fix(mobile): bound connection-log writes and flush the log before the app suspends The coalescing pass counted a pending persistence attempt per append and then burned that whole budget on unblock. With failing storage, 500 appends during a stall released ~1000 back-to-back `setItem` calls — and slow storage and failing storage are the same device condition, so the amplification fired in exactly the scenario the coalescing was for. The counter is gone. A single `dirtyHosts` flag replaces it: the host's revision always holds the newest entries, so counting appends bought nothing but writes. The loop re-reads the revision after each save, so a stall costs the in-flight snapshot plus one attempt at the newest one, whatever the append count. That also retires the compound `finally` condition and its unreachable `(… ?? 1) - 1`. A failed snapshot no longer gets an immediate second `setItem` against a store that just rejected. It gets one retry after 200 ms, and none at all once a newer snapshot is queued, because that snapshot already carries the same entries. `flush()` closes a data-loss gap that predates the coalescing: a write that failed was only retried by the next append, so when the disconnect was the last thing to happen the entries explaining it never reached storage. It drains the in-flight save and makes one more attempt at the newest snapshot, wired to AppState `background` the way `subscribeConnectionRevivalTriggers` wires resume. Two revisions tests asserted the retry budget as intended behaviour (6 writes for 3 appends; 3 for one failure) and now assert one write per snapshot generation instead. `connection-log-buffer.test.ts` is untouched, including its requirement that one transient failure self-heals without another append — that is what the single delayed retry keeps. Co-Authored-By: Claude <noreply@anthropic.com> * fix(mobile): type the background-flush test mock so the tests ratchet passes The new test copied `ReturnType<typeof vi.fn>` from connection-revival-triggers.test.ts, which is grandfathered in the tests-typecheck baseline for that exact TS2345. The ratchet only shrinks, so type the mock instead of adding a baseline entry. --------- Co-authored-by: Claude <noreply@anthropic.com>