syntaqxA large download through a cloud runner's egress that breaks off partway is resumed instead of failing the job. npm ci kept failing with ECONNRESET and "network aborted" (17 install steps over three days, one in thirty on g1t's machines, all cloud sandboxes): an answer broke off after its headers had reached the sandbox, and npm never retries a body that stops. Answers up to 8 MB were already read whole and fetched again, but the tarballs that take longest to arrive are larger and streamed as they came: @pagefind/linux-x64 is 50 MB, workerd 38 MB, mermaid 25 MB. Now a GET whose whole 200 answer is sent uncompressed with a known length, from a host that takes byte ranges and names a strong ETag or a Last-Modified date, streams through a body that counts what it has passed on; when the upstream breaks off or ends short, the rest is asked for with Range: bytes=<received>- and If-Range, after the same 250 ms and 1 s waits, and joined on only when the answer is a 206 for exactly that rest, so the sandbox sees one unbroken answer with its Content-Length kept. A host that sends the whole file again, or a file that changed, ends the body as before. Each break and each resumption is one line of the Worker's log (egress body broke off, egress body not resumed), so a reset that the Worker never saw is known to be between it and the sandbox. The Actions guide says how requests to allowed hosts are retried and resumed.1bb793aHistory
- ..
- 0001_init.sql
- 0002_projects.sql
- 0003_paused.sql
- 0004_redirects.sql
- 0005_domains.sql
- 0006_replaced_and_down.sql
- 0007_repo_deleted.sql
- 0008_detected.sql
- 0009_workspace_deleted.sql
- 0010_repo_deployments.sql
- 0011_workflow_builds.sql
- 0012_via_workflow.sql
- 0013_workflow_build_jobs.sql
- 0014_containers.sql
- 0015_telemetry.sql