From ed0dc4a7b9fefa9bade8ad7f465bf8ed74260512 Mon Sep 17 00:00:00 2001 From: gsxdsm Date: Mon, 8 Jun 2026 13:25:58 -0700 Subject: [PATCH] FN-6008: refresh FTS defer evidence Refresh the storage docs with updated evidence for deferring the separate live-FTS database migration. - update the FN-6008 live `tasks_fts` telemetry summary with current bounded size measurements - record the sampled maintenance-window merge/optimize counts and latest byte deltas - note the reviewed malformed-database log without overstating it as a recurring post-FN-5943 FTS issue Files changed: docs/storage.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) Fusion-Task-Id: FN-6008 Fusion-Task-Lineage: d8c7c05c-f003-453d-bbd1-d9f0dda62f7c --- docs/storage.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/storage.md b/docs/storage.md index dce114156b..63099763a2 100644 --- a/docs/storage.md +++ b/docs/storage.md @@ -176,10 +176,10 @@ Important execution nuance: - Why defer now: - FN-5943 already landed the lower-risk fix for the observed incident: fewer rewrites, bounded merge/optimize maintenance, and threshold-triggered rebuild. - FN-6008 rechecked the post-FN-5943 operational evidence against the live project DB and the defer condition still holds: - - recent `runAuditEvents` telemetry for `target: "tasks_fts"` shows the live index staying bounded in the **tens to low hundreds of KB**, not MB-scale bloat; - - the sampled maintenance window showed **0 rebuild events**, with `merge`/`optimize` repeatedly pulling the index back down (for example `141186 → 43990` bytes and `96571 → 40693` bytes); - - a direct `tasks_fts_data` size check during the review was only about **50 KB** for **36** live tasks; - - no concrete post-FN-5943 runtime evidence of recurring live `tasks_fts` corruption was found in the reviewed logs. + - recent `runAuditEvents` telemetry for `target: "tasks_fts"` shows the live index staying bounded in the **tens of KB**, not MB-scale bloat; + - the sampled 30-event maintenance window showed **0 rebuild events** (`23` merge, `7` optimize), with `merge`/`optimize` repeatedly keeping the index small (latest samples include `44076 → 43296` bytes and `53261 → 40449` bytes); + - a direct `tasks_fts_data` size check during the review was only **47884 bytes** for the current project DB; + - reviewed logs contained one general `database disk image is malformed` crash in an older merge-agent log, but no recurring post-FN-5943 live `tasks_fts` corruption pattern and no repeated FTS rebuild failures. - The attached-file idea still improves corruption isolation, but it would trade away the current same-file trigger-maintained index for a manual two-file sync architecture with weaker crash atomicity under WAL. - Revisit only if post-FN-5943 production evidence shows recurring `fusion.db`-coupled FTS corruption or materially persistent live-index bloat significant enough to justify a contentless/manual-sync redesign. Until then, keep the single-file external-content design and existing maintenance path.