You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
A timeline trace that started behind another writer never retries the lock, and flush() reports success while dropping spans #2706
The timeline trace opens its session directory once and keeps persist: false for the rest of the process when another writer already holds the lock. Nothing retries the lock afterwards, and flush() still answers ok: true, so every span appended after the other writer leaves is dropped while the caller is told the flush succeeded.
/data/dsh/bot/workspace/audit46/shutdown.test.mjs, test F4 (real modules, real child processes):
the first window opens the trace dir and flushes a span; the second window starts behind it: stats.persist === false, with not writable on stderr;
the first window exits; the second appends a span and flushes: { ok: true, stats: { persist: false } } — and the span is not on disk (traceText(dir).includes('after-the-writer-left') === false);
reverse control: a window opened after the writer exits takes the lock and persists (persist: true, span on disk).
Why it matters
Two windows on one home is normal, and a trace is diagnostics: it is exactly the second window whose spans explain what the first one did before dying. Today those spans vanish, and the flush reports success, so nothing anywhere records that the trace was incomplete — the stored trace reads as a complete account of what happened.
Expected
Either the lock is retried when it is needed (on flush, or on a timer), so a window that started behind another writer begins persisting as soon as the lock is free; or flush() reports the failure it has already detected (persist: false is not a success) and says it once per process, so a caller can tell "nothing to write" from "written nowhere". A test drives two real children and asserts the span reaches the disk after the first exits, or that the flush result is not ok.
Change scope
plugins/timeline/src/store.js (the lock acquisition and flush()'s result), plugins/timeline/src/timeline.js if the stats are shaped there, plus a test.
Activity
HugoXK commentedon Nov 8, 2026
Claim
Written-by: FlyBot Lead
Claimed-by: FlyBot Lead
Claim-Id: a092ef40d75741ad853d0ebe5b53cacc
Branch: dev/2706-a-timeline-trace-that-started-behind-ano
Base: 71855d9
At: 2026-11-08T19:31:54Z
Fix the timeline trace lock so a window behind another writer persists (
Release v0.2.28 (ThinkFlowLab#2777)