root/fusion
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

FN-6008: document FTS migration defer evidence and align workflow IDs

Browse Source 
Refresh the FTS migration guidance with fresh evidence and reconcile workflow interpreter naming.

- document post-FN-5943 production evidence showing the single-file tasks_fts index remains bounded and rebuild-free
- keep the storage guidance explicitly deferred until recurring corruption or sustained bloat is observed
- relax the foreach parser test to accept the current nested loop/foreach error wording
- align the authoritative workflow driver ID with the task branch change during conflict resolution

Files changed:
 docs/storage.md                                         | 7 ++++++-
 packages/core/src/__tests__/workflow-ir-foreach.test.ts | 2 +-
 packages/engine/src/workflow-authoritative-driver.ts    | 2 +-
 3 files changed, 8 insertions(+), 3 deletions(-)

Fusion-Task-Id: FN-6008

Fusion-Task-Lineage: d8c7c05c-f003-453d-bbd1-d9f0dda62f7c
This commit is contained in:
gsxdsm
2026-06-08 11:07:24 -07:00
parent fc91540a8a
commit ce4d0a899f
3 changed files with 8 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
docs/storage.md
View File

@@ -175,8 +175,13 @@ 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.
- 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.
- 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.
## SQLite write-path lock recovery (FN-4042 / FN-4083)