fix(cli): read the registry from HeyGen's CDN first, and say why when no host answers - #7014

Requesting changes at 685af416.

1. No fails without the fix: line. This lane requires a fix PR to name, on a line starting fails without the fix:, a test that fails without the fix. The body says "The 5 new transport and manifest tests fail on main" but doesn't name any of them on that line. For example: fails without the fix: transport.test.ts › "<name>", catalog.test.ts › "<name>".

2. The mirror's 4 s cap also aborts the response body, with no fallback. AbortSignal.any([signal, AbortSignal.timeout(MIRROR_WAIT_MS)]) is attached to the fetch whose Response is returned to the caller, so the 4 s keeps running while the caller reads the body. I checked this on Node 22: a 200 whose body streams for about 3 s under AbortSignal.timeout(1000) gets headers, then text() throws TimeoutError. In this PR that error happens outside both the mirror→raw fallback and fetchWithRetry, which only wraps the fetch. So once the mirror serves files, any registry file that takes more than 4 s in total fails the install. Examples are the 2.5 MB macbook.glb models and the 2 MB wav/png assets on a slow link, and slow links are the networks this PR targets. Today those succeed from raw GitHub within the caller's 10 s. Possible fixes: cap only the wait for headers and clear the timer once they arrive, or read the mirror body fully inside the fallback try. Please add a test with a slow-body mirror.

3. The mirror isn't serving the registry. https://static.heygen.ai/hyperframes-oss/desktop/registry/main/registry.json and …/blocks/aurora/registry-item.json both return 403 AccessDenied, which is S3's missing-key answer. Raw GitHub serves registry.json (200, 37.5 KB). Neither this repo nor hyperframes-internal contains a workflow that writes hyperframes-oss/desktop/registry/main, so I can't confirm "published there on every change to registry/ on main". As merged, every default-registry read worldwide makes one failing request to the CDN first, and blocked networks still get nothing. Please point to the publisher, or land it first, and confirm the mirror's registry.json matches raw GitHub.

4. Comments fails on this head. catalog.ts goes from 159 to 160 comment lines, and transport.ts goes from 1/44 to 4/83.

Looks right: fetchRegistryManifest keeps its undefined contract by wrapping readRegistryManifest. A stale cached copy is still served before any error. A custom registry is never rewritten to the mirror.

Requesting changes at 2987c132. Three of my four points are fixed. The mirror point is not answered.

Fixed, and verified locally:

• fails without the fix:: the line is now present, and the named tests fail at merge base cd598426 and pass at head. The three changed test files pass 111/111.
• Mirror cap: it now covers only the wait for the answer. The timer is cleared once the mirror answers, and the body reads under the caller's signal. With the clearTimeout after the answer removed, "leaves a mirror answer that came in time readable past the mirror's cap" fails, so the new test pins the fix.
• Comments: passes.

Still blocking: the mirror doesn't exist yet, and the body still says it does. As of this review, https://static.heygen.ai/hyperframes-oss/desktop/registry/main/registry.json and …/blocks/aurora/registry-item.json still return 403 AccessDenied. The body still says "The registry folder is published there on every change to registry/ on main". I found no publisher in this repo or in hyperframes-internal, and the update doesn't name one.

Until it's published, this PR:

• adds one failing CDN round trip, of up to 4 s on a slow or hanging route, to every default-registry read for every user, which on installs means every item file;
• does nothing for the blocked networks it's for.

Any one of these clears it:

• Link the workflow or job that publishes registry/ to that prefix, with the mirror's registry.json returning 200 and matching raw GitHub.
• Land the publisher first and re-pin this PR.
• Correct the body to say the mirror is not live yet, and state that merging ahead of it is intended. I'll approve on that if whoever owns the CLI's network behaviour accepts the extra request in the meantime.

Reviewed at caf52499d7cc633c3434afd0f362654754b9d137.

The header-wait cap now clears when the mirror answers, preserving the caller's budget for the response body (packages/cli/src/registry/transport.ts:49–54). Custom registries remain direct, and valid stale manifest fallback is preserved. The required fails without the fix: line is present.

Important — preserve raw-GitHub failure semantics when adding the two-host diagnostic (transport.ts:65–67). The new wrapper always throws a plain Error, while existing callers depend on the original error:

• registry/resolver.ts:67 switches later item batches to cache-only on TimeoutError. With mirror 403 and raw GitHub timing out, the wrapper hides that name. Actual loadAllItems with 100 uncached entries makes 100 raw + 100 mirror requests, compared with 32 raw requests on the unmirrored control. Only the 10-second timeout was accelerated to 25 ms; real abort signals drive the mock fetch. This changes one timeout wave into all waves. Extrapolation, not a production timing measurement: 448 uncached items at 32 concurrent could take roughly 140 seconds rather than one 10-second wave.
• registry/remote.ts:223–230 scans the complete diagnostic for TLS errors to decide retryability. Mirror ERR_TLS_CERT_ALTNAME_INVALID plus a transient raw ECONNRESET is classified as non-retryable, so the file fails after one raw request although a second would succeed. The unmirrored control retries and returns the file.

Fix: retain structured error metadata for the final raw attempt, including its timeout identity, while keeping both host reasons for display. Make retry classification use that raw failure rather than the mirror's diagnostic. A local control preserving the raw name and classifying the raw cause restores 32 requests and successful retry; it was restored afterward. Add two separate regressions through the real consumers: resolver stops new network batches after a raw timeout; file download retries raw ECONNRESET despite mirror TLS failure.

Important — publisher prerequisite remains unmet, as in Genesis's prior review and the author's explicit publisher-first agreement (transport.ts:33,43–51). Fresh HTTPS reads of both CDN registry.json and blocks/aurora/registry-item.json return 403 AccessDenied; raw GitHub's registry returns 200 (37,569 bytes). The body now correctly says the publisher must land first. Until then every uncached default-registry file gains a failing CDN request and the blocked-GitHub cohort still cannot load it. To clear: run the approved publisher, link its job, and show CDN registry 200 with identical bytes/SHA-256 to raw GitHub, plus blocks/aurora/registry-item.json and a file referenced by it returning the corresponding raw-GitHub content. No need to change the truthful body back.

Validation: full root bun run build passes; bun run --cwd packages/cli test src/registry/transport.test.ts src/registry/remote.test.ts src/commands/catalog.test.ts src/registry/resolver.test.ts reports 134 passed. Changed-file oxlint passes. The lane-named transport/remote diagnostic tests fail with mirror bypassed, and the slow-body-cap test fails with its timer cleanup removed; restored suite passes. Those check earlier fixes; the separate actual-consumer probes demonstrate the newly reported timeout and retry regressions. Fresh adversarial probes independently found the error-contract regression; I reran them and the proposed-fix control. Network availability is a point-in-time check, not a CDN publishing audit. No mainland-China or Desktop end-to-end run.

Need: yes · Size: ok · Reuse: existing resolver timeout guard and remote retry classifier · Simpler: keep final-attempt failure metadata separate from display diagnostics · Structure: fine
Risk: medium — changes shared registry transport and outage behavior.

Verdict: REQUEST CHANGES
Reasoning: The mirror cap is fixed, but the aggregate error breaks existing timeout/retry consumers, and the explicitly required mirror deployment is still absent.

— hf-review