6 Commits (43ec4d2fa3aaa36d8ea786d145268b8a2bf3f070)

Author	SHA1	Message	Date
diffwireauto	1b38c674e4	feat(#965): per-key migration timestamps and the stale-blob sweep ... Epic A of #962. The engine only; the manual action is #966. A1 wrote the diagnosis as failing tests first, and they were red for the right reason: no sweep existed and six BlobStore methods did not. Also lands a control test asserting that DELETE alone does not shrink the database, which passes today and must keep passing, since it is the entire reason a VACUUM step exists. A2, the timestamps. A second blob, __msgrows_migrated_at, keyed by store key. Deliberately NOT a reshape of __msgrows_migrated: that marker is read on every save and every load through a cache, so changing its shape would put a migration of its own on the hottest storage path. Owner decision 2026-10-22. An install that migrated before this ships has no timestamp, so backfillMigratedAt stamps it on FIRST SIGHT and the sweep skips anything it stamped this pass: updating the app can never delete a blob on the spot, and every key gets the full 30 days measured from when we first knew about it. A3, the sweep. Eligibility is age plus a fresh verification, never the marker alone, which is the difference between "we recorded that this migrated" and "we just confirmed it". missingFromRows returns null for "could not tell" and an empty list for "verified nothing missing", and those are deliberately different values: collapsing them is how the only copy of an unreadable history gets deleted. A4, one VACUUM, only when something was deleted. A failure there is logged and tolerated: the deletes already happened and were each verified, so it costs space and not data, and the next sweep retries it. The comparison rule now lives in ONE place, _absentFrom, used by both the migration gate and the sweep. The gate still decodes its own blob, because a second compute over multiple megabytes on the migration path would cost more than the duplication saves, so the rule is shared even though the decode is not. Wired into main.dart's existing post-frame callback, beside the #906 exit-info collector, for the same reason: storage hygiene must never be on the path to a usable screen. The catchError sits at that fire-and-forget call site rather than inside run(), so #966's button still gets a failure it can report. scoping_inventory gained the new key, because the #853 gate caught it exactly as designed. Its verdict is globalOnPurpose for the same reason as the marker: it is keyed BY store keys that already carry the radio. 15 tests, the plan's whole acceptance bar: the 29-day and 30-day boundaries; one missing row refuses AND the same key clears once its rows are complete, which is what proves the gate discriminates rather than never deleting; an undecodable blob refuses; an unstamped key is stamped not deleted; an unmigrated key is untouched; contacts, discovered_contacts and path_history_ are asserted non-candidates BY NAME; a DM key sweeps through the DM converter; and every kept blob is byte-identical across the sweep and VACUUM with the row count unchanged. A5, verification against a copy of the owner's real database through the production sweep: blob keys: 470, migrated history keys aged: 47 cleared 40, refused 0, 17367040 bytes returned (16.56 MiB) kept keys missing: 0, byte-changed: 0 integrity_check: ok, rows 29949 -> 29949 47 aged and 40 cleared because the other 7 migrated through the empty-blob path and never had a blob to reclaim. Full suite 1,469 pass, 1 skipped, up from 1,454. analyze clean, format clean. Task: meshcore-open-5vt Agent Mail: TealGlen Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	5f79c6e1db	fix(#943,#952): act on the Gemini gate findings ... Two of five findings were real. Log the downgrade refusal BEFORE the path lookup and the throw. onUpgrade runs inside drift's beforeOpen, so it fires on whichever isolate issued the first query, and whoever catches the exception decides what the user sees. A downgrade that only stopped background work, with nothing in the log, would be the quiet failure this branch exists to replace. The log line now lands first, so the record exists however the exception is handled. Strengthen the recovery bench. It asserted row COUNTS, so a converter producing the right number of rows with wrong contents would have passed. It now also checks that every identified blob record has a row carrying its identity, and that no payload is empty, both derived from the raw blob rather than from the converter under test so the check is not circular. Records with no messageId are not identity-checked, because reproducing the `x:` fallback key here would make it circular again; the count assertion still covers them. Verified on a copy of the owner's database with the trap reconstructed (the 6,308-message channel removed from the marker plus one planted row the blob does not contain): the key migrates, and all 6,308 identities are present. Then verified the new assertion can FAIL, by planting an empty payload the migration does not overwrite: Expected: empty Actual: WhereIterable<String>:['{}'] Three findings were rejected, with reasons in the PR body: the duplicate merge-key collapse is pre-existing and unchanged by this diff, the claimed migration/blob-save race cannot occur because of the re-check inside the per-key lock, and the path_provider call is bounded and already proven. Task: meshcore-open-lkp Agent Mail: TealGlen Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	e692562765	test(#952): prove the stuck keys recover against a real database ... The unit tests pin the invariant on fixtures. This runs the real migration code over a copy of an actual database and finds the stuck keys by shape, without using the code under test: a key that has rows and is absent from the migrated marker. On the owner's install, all 5 such keys migrate, 0 still refused: keys with rows: 41, marked migrated: 36, rows but unmarked: 5 MIGRATED blob=237 rows 238 -> 238 ...psk_43636021 MIGRATED blob=5646 rows 5648 -> 5649 ...psk_8b3387e9 MIGRATED blob=1578 rows 1585 -> 1585 ...psk_9cd8fcf2 MIGRATED blob=6308 rows 6313 -> 6313 ...psk_e3c26491 MIGRATED blob=16 rows 16 -> 16 messages_d549bbfbd060dae1... psk_8b3387e9 is the one worth reading twice: 5,648 rows became 5,649. That key held 3 rows the blob does not have AND one blob record that had never reached a row. The old gate saw unequal totals and refused, so that record stayed unreachable from rows indefinitely; the superset check inserts it and then verifies it is there. Asserts no key loses records, every migrated key ends up marked, and every retained blob is still present, so the run is non-destructive beyond the copy it works on. Reports and skips when BENCH_DB is absent, and says explicitly that a database with no stuck keys is not a pass. Task: meshcore-open-lkp Agent Mail: TealGlen Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	c4e28b653d	task(#937): B4 Epic B verification, rehearsed on a real prefs file ... Rehearsed the legacy purge against a copy of the owner's live prefs, 2,149 keys and 4,277,260 bytes: purged 2,095 path-history keys, global observation list: yes legacy keys left: 0 prefs keys remaining: 53 this radio's scoped history: intact That last line is the point of the rehearsal. The purge removes the unscoped legacy keys and leaves the scoped history alone, which is only safe because the two live in different backends: new keys in drift, legacy in prefs. **The harness reports its own timings as NOT the real cost, loudly.** It measured a 4 ms worst UI block, and that number is worthless: the SharedPreferences test mock is an in-memory map and does not do the whole-file re-encode and rewrite every real `remove` performs on Windows. A time threshold here would pass no matter how slow production was, so there is deliberately no time assertion. The real figures come from simulating the plugin's actual behaviour against the same file: 12.7 s total, mean 6.1 ms, 32 ms for the first removal falling under 1 ms by the last as the file collapses 4.28 MB to 45 KB. That is why the purge yields every 20 removals. Flagging it rather than quietly reporting 4 ms, because a harness that measures the mock instead of the mechanism is the third false-green this session would have produced: the #919 heartbeat that read 0 ms, the #920 readback gate that compared a converter to itself, and this. **The 45 KB endpoint also means #923 is largely neutralised in practice.** Every remaining prefs write drops from ~32 ms to well under 1 ms, because 86% of the file is gone. The mechanism is untouched and #923 stays open, as the plan says, but its blast radius is now small. **Suite:** 1,414 pass, analyze clean, format clean. Epic B is complete: #855 deleted, #854 and #856 scoped per radio, #924 resolved, and the inventory's known-holes set is empty. Citadel: meshcore-open-sgu Refs #937, #854, #855, #856, #923, #924, #853 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	dbe52164da	task(#920): B4 Epic B verification against the owner's real database ... Ran the migration over a copy of the live 41.17 MiB database, 138 message history keys: keys migrated : 138 of 138 records in blobs : 64,883 rows stored : 64,883 elapsed : 4,382 ms Exact parity, no refusals. Every blob is byte-identical afterwards, checked by length and content hash per key, which is the promise that makes this recoverable. Per-message save cost against history length, median of 20: 500 messages 0.124 ms 5,000 0.126 ms 50,000 0.133 ms A hundred times the history for 1.07x the cost. The Feature's "done when" was that receiving a message costs the same at 50,000 messages as at 50, and that is now true. For contrast, the blob path blocked the UI for 381 ms at 9,230 messages. One-time migration cost for the worst key, 5.38 MiB and 9,230 messages, with the heartbeat harness from #919: UI blocked 64 ms wall 447 ms (30 heartbeats) So the first open of the biggest channel after this ships costs a 64 ms hitch on this desktop, once, and the UI stays live through the rest. That number needed a correction before it could be reported. The first run measured 166 ms, because the harness opened the database with a plain `NativeDatabase`, which executes SQL on the calling isolate. Production uses `drift_flutter`'s `driftDatabase()`, which hosts the connection in a background isolate, so the harness was charging the UI isolate for work that does not happen there. Switched to `NativeDatabase.createInBackground`, which is the shape that ships: 64 ms. The parity test refuses to invent data: without `--dart-define=BENCH_DB` it prints that it measured nothing rather than synthesising a database, and it copies the file it is given rather than writing to it. Citadel: meshcore-open-i8t Refs #920, #917, #334 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	d791c58fea	task(#919): A5 Epic A verification: isolate gate + block-time benchmark ... Two things the Epic needed and did not have: a gate that fails if the work comes back to the UI isolate, and a number for how much it was blocking. The gate is structural, not timed. The merge callback reports the isolate it ran on, and the test asserts that is not "main". `compute` names the worker it spawns after the callback, so the recorded name also says which worker. A wall-clock threshold would have been flaky on CI and would not say why it passed. The benchmark runs a 1 ms heartbeat on the main isolate and reports the worst gap between beats, which is the UI freeze an ANR is. It is named `_bench`, not `_test`, so a bare `flutter test` skips it: it needs a local copy of a real database and the numbers are machine-dependent. Measured against the owner's real largest channel, 5,650,194 chars (5.39 MiB), 9,230 messages, on this desktop: UI blocked wall heartbeats 1 save, inline (pre-919) 381 ms 381 ms 1 1 save, off-thread 44 ms 297 ms 174 5 saves, inline 1,385 ms 1,385 ms 1 5 saves, off-thread 66 ms 1,496 ms 964 8.7x less blocking on one save, 21x on a burst of five. Wall time barely moves, which is the plan's point: the work is not cheaper, it is elsewhere. Inline, UI-blocked equals wall and one heartbeat lands in 1.4 seconds; the UI isolate was gone for the whole operation. Off-thread it beats 964 times through the same burst. The first measured support for the burst claim, which until now was arithmetic. Still desktop, not a phone: that is the owner's device check. The heartbeat needed a fix before it could be trusted. A periodic timer cannot fire while the isolate is blocked, so cancelling it the moment the action returns discards the tick that would have shown the gap, and the first run of this benchmark duly reported the inline path blocking 0 ms. Verified on a bare 200 ms busy-wait: no trailing yield gives fires=0, worst=0 ms; with a yield it gives 200 ms. It now yields before cancelling and reports the heartbeat count so a dead instrument cannot read as a clean result. Citadel: meshcore-open-xxc Refs #919, #917, #334 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago