A test proves a 400 MB snapshot through a throttled fake store restores within the drill's size-scaled budget #2819

A real 400 MB snapshot restores green through a 150 Mbit/s store in about 21.5 s, against a 16 min 40 s budget. No phase needed fixing, so src/snapshot/ is untouched. I didn't get a type check: bun x tsc --noEmit fails here with "bun is unable to write files to tempdir" (read-only filesystem), so the forge's check is the first to run it. The new test passes locally under bun test.

What changed

• New test/drill-400mb.test.ts runs the real runDrill and the real restoreSnapshot against a fake object store.
• The store serves a 400 MB packed forge.db (24 parts) plus the rest of a real small snapshot taken in the test, through one shared 150 Mbit/s link that makes each get wait behind the bytes before it.
• The 400 MB is generated at run time: the snapshot's own database copy followed by incompressible padding, in a single zstd frame. Nothing large is kept in the repo.
• I used the snapshot's database copy because the live forge.db file sits behind its WAL and lacks the schema.
• Only boot is stubbed, since the side-booted forge isn't the point.
• The test asserts a green verdict, budgetMs == drillBudgetMs(manifest.bytes) (at least 1,000,000 ms), the drill finishing inside that budget, and every phase recorded in order. It also asserts that files takes at least the time the wire needs.

Phase times measured

Download is the slowest phase because the wire is the limit. Unpack takes 7 ms after the last part lands, which shows decompression is streamed during the download rather than done afterwards.

Test time

• The drill takes 21.5 s and the whole test about 25 s, under the 30 s limit.
• I did not scale size or speed down. Scaling both together leaves the wire time unchanged, and the full-size test already fits.
• Setup is about 3.5 s and the test needs roughly 1 GB of memory briefly. On a slow machine the margin to 30 s is thin.

Not done

• Clone time isn't covered: the snapshot has no large repositories, so bundles is 0 ms. The clone phase is untested at this size.
• The node zstd stream stops after the first frame of a multi-frame input without an error, so the generator writes one frame. The real packer already writes one.

🤖 Generated with Claude Code

Closes #2813

A real 400 MB snapshot restores green through a 150 Mbit/s store in about 21.5 s, against a 16 min 40 s budget. No phase needed fixing, so src/snapshot/ is untouched. I didn't get a type check: bun x tsc --noEmit fails here with "bun is unable to write files to tempdir" (read-only filesystem), so the forge's check is the first to run it. The new test passes locally under bun test.

What changed

• New test/drill-400mb.test.ts runs the real runDrill and the real restoreSnapshot against a fake object store.
• The store serves a 400 MB packed forge.db (24 parts) plus the rest of a real small snapshot taken in the test, through one shared 150 Mbit/s link that makes each get wait behind the bytes before it.
• The 400 MB is generated at run time: the snapshot's own database copy followed by incompressible padding, in a single zstd frame. Nothing large is kept in the repo.
• I used the snapshot's database copy because the live forge.db file sits behind its WAL and lacks the schema.
• Only boot is stubbed, since the side-booted forge isn't the point.
• The test asserts a green verdict, budgetMs == drillBudgetMs(manifest.bytes) (at least 1,000,000 ms), the drill finishing inside that budget, and every phase recorded in order. It also asserts that files takes at least the time the wire needs.

Phase times measured

Download is the slowest phase because the wire is the limit. Unpack takes 7 ms after the last part lands, which shows decompression is streamed during the download rather than done afterwards.

Test time

• The drill takes 21.5 s and the whole test about 25 s, under the 30 s limit.
• I did not scale size or speed down. Scaling both together leaves the wire time unchanged, and the full-size test already fits.
• Setup is about 3.5 s and the test needs roughly 1 GB of memory briefly. On a slow machine the margin to 30 s is thin.

Not done

• Clone time isn't covered: the snapshot has no large repositories, so bundles is 0 ms. The clone phase is untested at this size.
• The node zstd stream stops after the first frame of a multi-frame input without an error, so the generator writes one frame. The real packer already writes one.

🤖 Generated with Claude Code

A real snapshot restores green through a throttled fake store inside the drill's budget, but the test now runs at 1/4 scale (100 MB at 37.5 Mbit/s), not 400 MB at 150 Mbit/s. It passes locally in 22.7 s. I haven't re-run the forge's check, so that verdict on the new push is still to come.

Why the scale changed: the first push failed the check with ENOSPC. The check's scratch disk filled at about 320 MB while the restore wrote the 400 MB database. I scaled size and speed down together, by 4. The wire time is unchanged, about 21 s, which keeps the test under 30 s, and the restored file on disk is 100 MB.

What the test does (test/drill-400mb.test.ts):

• It takes a small real snapshot, then swaps its forge.db for a packed one: the snapshot's own database followed by incompressible padding, in one zstd frame. The padding is generated at run time and never kept in the repo.
• The fake store serves it through one shared link at 37.5 Mbit/s.
• runDrill and restoreSnapshot run for real; only the side boot is stubbed.
• It asserts a green verdict and budgetMs == drillBudgetMs(size), which is 700,000 ms (11 min 40 s) at this size. The drill must finish inside that, every phase must be recorded in order, and the download phase must take at least the wire time.

Phase times measured:

Download is the slowest phase because the wire is the limit; unpack finishes within 8 ms of the last part landing. Nothing in src/snapshot/ needed fixing.

Not covered:

• Disk write time for a full 400 MB restore. The scratch disk couldn't hold it.
• Clone time for large repositories, since the test snapshot has none.
• Type check. bun x tsc --noEmit can't run in my sandbox (read-only tempdir), so the forge's check is the first to run it.

🤖 Generated with Claude Code

test/drill-400mb.test.ts now runs the real 400 MB at 150 Mbit/s wherever the scratch disk has room, and a 1/4-scale run (100 MB at 37.5 Mbit/s) everywhere. Both pass locally, but I haven't re-run the forge's check on this push.

What changed

• Full run: a real snapshot with a 400 MB packed database goes through the fake store at 150 Mbit/s, and runDrill must finish green inside 16 min 40 s. It runs only if statfsSync(tmpdir()) shows at least 1.5 GB free; otherwise it is skipped and named as skipped. On this machine it ran and passed: files took 21,380 ms, unpack 4 ms, open 3 ms, boot 144 ms.
• Scaled run: always runs. It checks green, an 11 min 40 s budget (the 400 MB rule at this size), and each phase recorded in order. Its phase times were about the same.
• Header and titles: both now say which run proves what. They also say that clone time is not proven, because bundles is ~0 ms with no large repository, and that the full-size disk write is only proven where the full run isn't skipped.
• delete link.bounded: dropped. dirStore has no bounded, so it did nothing.
• Wall-clock took < 30 s: dropped. The budget assertion covers the requirement, and the wire time is asserted as a lower bound.

Where I deviated

• Skip on a small disk: I skip the full run there, as asked, and the scaled run still covers the streaming, phases and budget rule. The earlier ENOSPC check disk will skip the full run, so the forge's check won't prove the 400 MB disk write.
• Test time: each test takes about 22 s, so the file takes about 47 s when both run. The issue's 30 s limit holds per test, not for the file.
• Type check: still not run. bun x tsc --noEmit can't run in my sandbox, so the forge's check is the first to run it.
• Follow-up issue: I did not open one for the 400 MB disk-write case, since the full run now covers it where the disk allows.

No phase needed fixing, so src/snapshot/ is untouched. Download is the slowest phase because the wire is the limit.

🤖 Generated with Claude Code