app

Adom Hydrogen

Public Made by Adom

by adom

The whole Adom experience as one signed native app: your editor, your AI agent, and the full electronics design toolchain, running locally on your own machine.

Overview Files Skills Discover Packages Releases Dependencies Issues20 Breadcrumbs Pull Requests Activity
Closed general

Prefetch the golden image at setup start and resume it across the WSL2 reboot (byte-range resume; host verified 206)

John Lauer · 1mo ago ·closed by John Lauer

Kyle's idea, relayed by John 2026-09-04: start the golden image download the moment the setup cascade starts, so it overlaps the slow steps (enabling WSL2, which needs a reboot) and people on slow internet are not waiting at the image step later. John's follow-up: the WSL2 reboot would abandon a download that is 30% done, so it has to resume where it left off.

What exists today (runtime/wsl.rs, download_tarball)

  • The image is fetched at the ensure-workspace step, which runs AFTER ensure-wsl (the reboot). So on a fresh machine the 663 MB download does not even begin until after the reboot.
  • It streams to <LocalAppData>/.../cache/adom-golden.tar.gz.part with File::create, which truncates: a .part left by a reboot is thrown away and the download restarts from byte 0.
  • A completed adom-golden.tar.gz is reused if its SHA-256 matches the pin (verified-cache fast path), and DOWNLOAD_LOCK already serialises the two cascade entry points (startup auto-run and the post-reboot resume detector) so they cannot interleave into one .part.

Verified from the cloud, 2026-09-04

curl -I -r 0-0 on the v27 asset (redirected to release-assets.githubusercontent.com) returns HTTP 206, accept-ranges: bytes, content-range: bytes 0-0/694902658. Byte-range resume needs nothing from the host.

Plan

  1. Prefetch at cascade start. Spawn download_tarball as a detached task the moment the cascade begins, before ensure-wsl. The image step later either hits the verified-cache fast path or waits on DOWNLOAD_LOCK for the in-flight download, exactly as the post-reboot resume detector does today. Progress goes to the same on_pct channel so the setup UI can show "image 31% in the background" while WSL2 installs.
  2. Byte-range resume. On entry, if .part exists: read its length N, send Range: bytes=N-; on 206 open the file for append and continue; on 200 (range ignored) truncate and start over; on anything else, error as today. Keep the SHA-256 verification at the end unchanged, so a bad resume is caught the same way a bad download is.
  3. Sidecar so a stale part is never resumed. Write adom-golden.tar.gz.part.json with {url, sha256, total} when the download starts. On resume, if the pinned URL or sha differs (a version bump between reboot and relaunch), discard the .part. Also discard if N is greater than total.
  4. Reboot survival is then free. The .part and sidecar are on disk; Hydrogen autostarts after the WSL2 reboot; the cascade resumes at its incomplete step; the prefetch is re-armed at cascade start and continues from byte N.
  5. Do not fight the reboot. Before the cascade triggers the reboot, let the in-flight chunk finish (a few hundred KB) and flush; the .part length is then exactly what the resume sends.

Not in scope: multi-connection or throttled downloads. The single stream is already the fastest a home connection gets.

2 Replies

John Lauer · 1mo ago

Shipped in ah 1.0.202 (insiders) and field-verified on winvm with a fresh install, 2026-09-04.

Prefetch (first reset, cache empty, 500 Mbps Azure link):

13:13:39.784 [run_all_wsl] no workspace distro yet: prefetching the golden image in the background
13:13:40.159 [wsl-tarball] fetching .../v27-full/adom-golden-v27-full.tar.gz (resume from byte 0)
13:13:44.480 [wsl-tarball prefetch] golden image: 157/663 MB (24%) @ 432.3 Mbps
13:13:45.141 [run_all_wsl] RUN 'ensure-workspace' (status was Pending)      <- first real step, image already 24-35% down
13:13:51.976 [wsl-tarball prefetch] golden image downloaded, 663 MB in 10s

The download starts 5 s before the cascade's first step. On a home link that is the whole WSL2 install and restart spent downloading.

Resume (second reset that kept the cache; a 200 MB partial of the real image plus its sidecar staged in the cache dir, exactly what a mid-download reboot leaves):

13:22:48.975 [wsl-tarball prefetch] resuming the golden image download from 200 MB (left by an earlier attempt, likely the WSL2 restart)
13:22:48.976 [wsl-tarball] fetching ... (resume from byte 209715200)
13:22:49.427 [wsl-tarball prefetch] downloading golden image, 663 MB total, 200 MB already here
13:22:54.515 [run_all_wsl] RUN 'ensure-workspace'                            <- cascade starts while the resumed download is at 67%
13:22:57.729 [wsl-tarball prefetch] golden image downloaded, 663 MB in 8s
13:23:05.472 [wsl-tarball] SHA256 OK (694902658 bytes)

Byte 209,715,200 onward came over a Range request (the host answered 206), the file was appended, the hash matched the pin, and the import used it. Both cascades completed to a healthy workspace.

Not exercised: a real WSL2 reboot mid-download (the VM already has WSL2). The reboot path is the same code: the .part and sidecar survive on disk, Hydrogen autostarts, the cascade resumes at its incomplete step and re-arms the prefetch, which resumes as above.

John Lauer · 1mo ago

Verified in ah 1.0.202 on a fresh install (two cascades on winvm): prefetch starts 5 s before the first setup step, and a staged 200 MB partial resumes over a byte-range request, passes the hash check, and imports. Log evidence in the comment above. Closing; the real-reboot path shares the same code and is covered by the cascade's existing post-reboot resume.

Log in to reply.