6 Commits (ee5afefb7185635ebe642aeee75720b33f0fb284)

Author	SHA1	Message	Date
Strycher	3ff272ad8c	fix(#343): close the data-loss holes found by Gemini review ... Adversarial review (standards#145) of the storage/migration surface found four real defects, all data-integrity. All confirmed against the code and fixed; no false positives. BLOCKER - concurrent save race. saveChannelMessages / saveMessages are read-modify-write with an await gap, so two saves to the same key raced and the second clobbered the first, silently losing messages (e.g. a message and its delivery ack arriving together). BlobStore now provides synchronized(key, ...), a per-key operation chain; every RMW - merge-save, remove, and the load-path legacy migration - runs through it. Different keys stay concurrent. New test fires two concurrent saves and asserts the union survives. BLOCKER - non-atomic DB relocation. The documents->support move copied and deleted each file (.sqlite/-wal/-shm) in turn, so a failure after the main file moved stranded the DB across two locations and corrupted it. Now copies all files, verifies each by size, and only then deletes the sources; on any failure it rolls back the destination and leaves the original intact. MAJOR - load-path legacy migration raced save. The #194 index->PSK adoption did a blind write to the PSK key that could clobber a save that landed first. It now runs under the key lock and MERGES (union) instead of overwriting, so both the adopted history and any fresh message survive. MINOR - channel merge key lacked a sender. Two senders posting identical text at the same timestamp without a messageId would collide and lose one. The key now includes the sender, matching MessageStore. flutter analyze clean, dart format clean, 509 tests pass. Full Gemini log in docs/llm-consultations/.	2 days ago
Strycher	2fefb6aa91	fix(#343): keep full message history; window only in memory ... The persisted store was being overwritten with the windowed in-memory list, so any channel or DM with more than _messageWindowSize (200) messages lost everything older than the newest 200 on the first save after load. Observed live: Public went 232 -> 201 in one session on a build that already had the #333 fix, so this was not the race - it was windowing truncating the store. This is the slow-erosion cause behind the whole 566 -> 231 -> 206 -> 201 history. saveChannelMessages / saveMessages now MERGE into the persisted set instead of overwriting: upsert by message identity so older persisted messages are kept, new ones added, and the in-memory copy wins for edits/reactions/status. If the existing history fails to decode, the save aborts loudly rather than merging into an empty base and truncating (SAFELANE 6). Deletion is now an explicit path - removeChannelMessage / removeMessage - since the app deletes individual messages. Routing delete through the merging save would resurrect them; the connector's deleteChannelMessage / deleteMessage now call the explicit remove. Windowing stays for display and memory; it no longer dictates what is stored. Tests: 250-message history survives a 200-window save; new message appends; edit is captured not duplicated; delete does not resurrect. 508 pass, analyze and format clean. Cost: a save now re-reads and re-encodes the channel/contact history. Cheap with drift's per-key writes (#335); a future append-only schema removes even that.	2 days ago
Strycher	06d3f027dd	test(#335): make the drift asset-version guard line-ending agnostic ... The guard read pubspec.lock with a newline-sensitive regex, so it passed on LF (CI) and failed on CRLF (Windows) for the same, correct assets. A guard that is itself platform-fragile is worse than none. Normalise CRLF->LF before matching. Surfaced by the 290+306+335 integration merge, where the lockfile came through with CRLF endings.	2 days ago
Strycher	a2c7302aad	feat(#335): migrate bulk data from SharedPreferences into drift ... Moves message history, contacts and discovered contacts out of the settings store. Settings stay in SharedPreferences, which is what it is for. Ordering is the whole safety argument: WRITE, VERIFY BY READING BACK, and only then remove the source. #333 was a storage path that chose a key silently and made 566 real messages read as empty; deleting before verifying would make that class of mistake permanent instead of cosmetic. On any failure the source is left intact and the error is logged - never a silent drop (SAFELANE 6). Idempotent by construction: a key already present in drift is not overwritten, so re-running is a no-op. If an older build re-writes a migrated key into prefs, the migrated copy wins and the stale prefs copy is discarded rather than promoted. Rehearsed against a COPY of a real 7 MB store, as the plan required before touching live data: REHEARSAL: 69 migrated, 0 failed, 5.21 MB, 69 bulk keys expected Every key checked for exact length, confirmed removed from prefs, and every settings key confirmed untouched. The live store was never opened. Two things the tests caught that review would not have: 1. getString THROWS on a non-string value rather than returning null, so a non-string under a bulk prefix was counted as a migration FAILURE. It now type-checks with prefs.get() and skips. Alarming falsely is its own bug. 2. The `contacts` prefix was checked against the real store rather than assumed: it matches only the 6 bulk contact blobs, and correctly does NOT match contact_unread_count*. Not yet wired into app startup - that is the switchover, and it is deliberately a separate commit so this can be reviewed on its own. flutter analyze clean, dart format clean, 504 tests pass.	2 days ago
Strycher	c25b7ccbdf	chore(#335): pin drift, commit pubspec.lock, guard the web asset version ... Owner asked whether the web assets must be re-downloaded on every drift bump. They do not - the version can be pinned - but doing that safely needed three changes, because the failure mode is silent. 1. drift and drift_flutter are pinned EXACTLY (2.34.2 / 0.3.1), no caret. The committed web assets are built for a specific drift release, so a caret would let pub resolve a newer drift than the shipped binaries and break the web build with no signal at compile time. 2. pubspec.lock is now committed (removed from .gitignore). It was ignored, which for an application means resolution can differ between machines and CI. That undermines the pin: the assets are matched against the RESOLVED version, so resolution has to be reproducible. Owner-authorized, and it is a repo-wide change rather than a storage-only one. 3. New test asserting the shipped assets match the resolved drift version, plus that both files exist and the wasm really starts with the WebAssembly magic bytes. Verified in both directions: it passes when matched and fails loudly with re-download instructions when skewed. Without (3) a stale asset compiles, deploys, and only fails in the user's browser - the exact silent-failure class SAFELANE 6 forbids and that produced #333 earlier. Upgrading drift is now a deliberate step: bump the pin, re-download both assets, update web/drift_assets.version. The test fails until you do. flutter analyze clean, tests pass.	2 days ago
Strycher	19858698ee	feat(#335): add drift and prove it opens on the targets buildable here ... Step 1 of #335, deliberately before any data migration: prove the store works before trusting it with message history. Adds drift + drift_flutter, a key/value StoredBlobs table mapping 1:1 onto the existing SharedPreferences keys, and verifyReadWrite() as a runtime probe. Key/value rather than relational tables on purpose: it maps directly onto the current store interfaces, so callers do not change and the migration can be verified row-for-row against the old keys. Relational schemas come later, once this is proven and querying is actually wanted. Verified here: - 3 tests pass, including a 6 MiB round-trip - larger than the 5 MiB localStorage cap that makes the web build impossible today - flutter analyze clean - Windows release build succeeds - Web release build compiles Two findings from the gate that a plan-on-paper would have missed: 1. sqlite3_flutter_libs 0.6.0+eol is a DEPRECATED no-op. From sqlite3 v3.x it is unnecessary and drift_flutter already covers it, so it is not a direct dependency here. 2. The web build COMPILES BUT WOULD FAIL AT RUNTIME: drift needs sqlite3.wasm and drift_worker.dart.js shipped in web/, and neither is present. Per drift docs they are downloaded from GitHub releases, version-matched to pubspec.lock (drift 2.34.2, sqlite3 3.5.0), and the server must serve .wasm as Content-Type: application/wasm. Not done here - downloading files needs explicit human approval. Also noted: the drift_dev CLI does not compile at these versions (allSchemaEntities missing from the drift3_preview GeneratedDatabase), so its asset tooling is unavailable. build_runner code generation is unaffected. No user data is touched. No store is switched over. The migration is the next step and remains gated on the web assets question.	2 days ago