Skip to content

Startup restore feedback: a relaunch reports the prior capture's reopen in the status bar - #575

Draft
thebhef wants to merge 1 commit into
fix-plot-y-scalefrom
fix-startup-restore-feedback
Draft

thebhef wants to merge 1 commit into
fix-plot-y-scalefrom
fix-startup-restore-feedback

Conversation

@thebhef

@thebhef thebhef commented Oct 22, 2026

Copy link
Copy Markdown
Owner

On launch over a prior capture the window sat with empty plot and trace
views and no feedback for as long as the reopen took - 12-14 s on a
110 M-frame capture - because restore_scratch_capture is fired and not
awaited and emitted nothing while it ran. The only notice that existed
started after it returned, and only when the signal caches had to be
rebuilt.

Host (ADR 0002 DS-7, ADR 0047, ADR 0048): every expensive phase of the
restore maps segment files through open_segments, which now takes a
per-file callback (one atomic add per file, on the mapping threads).
It is threaded through ByIdIndex::reopen,
DiskRawStore::reopen_reporting, SampleSeq::reopen_many_reporting,
TraceStore::try_reload_reporting and
SignalCacheStore::restore_reporting; the non-reporting entry points
keep their signatures as wrappers. The pyramid restore plans both sets
before mapping either, so its total is known up front.
restore_scratch_capture emits restore-progress
{ phase, files_opened, total_files } with phases capture_index,
capture_frames (metadata, then payload - the total grows once) and
signal_caches: a first report at 0 of N unpaced, paced reports at the
live-update cadence, a last at N of N. Nothing is emitted when there is
nothing to restore. The reporter takes neither store lock. Reload cost
with and without the seam is noise (2088 files, debug: 113.0 vs 109.4 ms
and 102.5 vs 101.3 ms medians of 15).

Frontend: RestoreProgress mirrors the record; ProgressReport gains
the variant and loadProgressReadout renders " n / N files";
App listens for the event and shows "Restoring prior capture..." with
the same determinate chip the load and cache rebuild use, from the
first report until the invoke settles (a run counter ignores a late
paced report and keeps an older restore from clearing a newer one's
chip). The chip shares the cache-rebuild rule; no new tokens, no button.

Tests: the seam sees every file exactly once on the threaded and
single-file paths; reporter shape and pacing; an end-to-end reload over
a generated scratch and persisted pyramids reports the three phases in
order against on-disk file counts; readout cases per phase; App dom
tests for appear/leave on resolve, leave on reject, late report ignored,
nothing to restore shows nothing. README's relaunch paragraph describes
the chip.

Co-Authored-By: Claude Fable 5.1 noreply@anthropic.com

This was referenced Oct 22, 2026
This was referenced Oct 22, 2026

thebhef commented Oct 22, 2026

Copy link
Copy Markdown
Owner Author

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

This stack of pull requests is managed by Graphite. Learn more about stacking.

…en in the status bar

On launch over a prior capture the window sat with empty plot and trace
views and no feedback for as long as the reopen took - 12-14 s on a
110 M-frame capture - because `restore_scratch_capture` is fired and not
awaited and emitted nothing while it ran. The only notice that existed
started after it returned, and only when the signal caches had to be
rebuilt.

Host (ADR 0002 DS-7, ADR 0047, ADR 0048): every expensive phase of the
restore maps segment files through `open_segments`, which now takes a
per-file callback (one atomic add per file, on the mapping threads).
It is threaded through `ByIdIndex::reopen`,
`DiskRawStore::reopen_reporting`, `SampleSeq::reopen_many_reporting`,
`TraceStore::try_reload_reporting` and
`SignalCacheStore::restore_reporting`; the non-reporting entry points
keep their signatures as wrappers. The pyramid restore plans both sets
before mapping either, so its total is known up front.
`restore_scratch_capture` emits `restore-progress`
`{ phase, files_opened, total_files }` with phases `capture_index`,
`capture_frames` (metadata, then payload - the total grows once) and
`signal_caches`: a first report at 0 of N unpaced, paced reports at the
live-update cadence, a last at N of N. Nothing is emitted when there is
nothing to restore. The reporter takes neither store lock. Reload cost
with and without the seam is noise (2088 files, debug: 113.0 vs 109.4 ms
and 102.5 vs 101.3 ms medians of 15).

Frontend: `RestoreProgress` mirrors the record; `ProgressReport` gains
the variant and `loadProgressReadout` renders "<phase> n / N files";
`App` listens for the event and shows "Restoring prior capture..." with
the same determinate chip the load and cache rebuild use, from the
first report until the invoke settles (a run counter ignores a late
paced report and keeps an older restore from clearing a newer one's
chip). The chip shares the cache-rebuild rule; no new tokens, no button.

Tests: the seam sees every file exactly once on the threaded and
single-file paths; reporter shape and pacing; an end-to-end reload over
a generated scratch and persisted pyramids reports the three phases in
order against on-disk file counts; readout cases per phase; App dom
tests for appear/leave on resolve, leave on reject, late report ignored,
nothing to restore shows nothing. README's relaunch paragraph describes
the chip.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@thebhef
thebhef force-pushed the fix-startup-restore-feedback branch from fd32b6c to adb3894 Compare October 26, 2026 22:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant