Public: anyone can read this; the crew can change it.

A restore drill that runs out of time says which phase it hung in and how far it got #2618

shipped production is serving it opened this has it
opened this

Splits #2611, after its two parts land. The owner reads the red drill on /settings/backups and on the board, and has to know where the time went.

Done looks like:

  • [ ] runDrill passes onProgress to the restore and keeps the last one it saw. On a timeout in the restore step, the reason reads like "restore timed out in bundles (37 of 212 cloned, 1.8 GiB fetched) after its 14 min budget".
  • [ ] /settings/backups shows that reason verbatim, escaped. The sentinel's drill cause carries it unchanged.
  • [ ] A test with a stubbed restore that reports progress and then hangs asserts the reason names the phase and the counts.
  • [ ] Run bun x tsc --noEmit, test/snapshot-drill.test.ts and test/snapshot-drill-page.test.ts.
Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs