fix(advisories): a mid-download failure in advisories sync loses the network hint and says only 'terminated'

Note: this is an in-house item already being handled by the maintainer - not open for contribution. Filed for tracking only.

Surfaced by #1137, which narrowed getNetworkErrorHint's catch-all CA fallback to errors that start with OSV or contain fetch failed. That change is correct. It revealed that osv-sync.ts was relying on the catch-all.

The hole

cve-lite advisories sync reads the OSV dump body through readResponseBytes (src/advisory/osv-sync.ts:103), streaming via response.body.getReader(), with no try/catch. The fetchImpl(sourceUrl) call at :96 is also unwrapped.

A connection that dies mid-download therefore reaches the top-level catch raw:

name=TypeError  code=-
message="terminated"
cause=SocketError: other side closed

Reproduced with a local server that writes headers then destroys the socket.

"terminated" matches neither half of the new gate, so the CA hint is not shown. Before #1137 the catch-all covered it.

Why it matters

No ca-cert needs to be configured for this, so it is the default path. A proxy killing a roughly 100MB download is a plausible corporate-network symptom, and the corporate-proxy user is exactly who that hint exists for (it came from the SSL report in #395, fixed in v1.18.1).

The user also currently sees a bare Error: terminated, which says nothing about what was being downloaded.

Fix direction

Wrap at the source rather than adding another literal to network.ts. Put both the fetchImpl(sourceUrl) call and the readResponseBytes call behind a try/catch that rethrows as:

OSV dump download failed: ${message}

That joins the OSV prefix the module already uses everywhere else, so the existing gate covers it with no change to network.ts, and it also fixes the uninformative bare message. Adding "terminated" to the gate would work but spreads network knowledge back into network.ts, which is the opposite of what #1137 was for.

Also worth doing while in there

Three errors that are explicitly not network failures currently get the CA hint anyway, because they start with the prefix: the OSV batch no "results" array case, the response length mismatch case, and OSV result identity mismatch at index N (src/scanner.ts:208). Pre-existing and unchanged by #1137, but it means the stated principle is not fully achieved. Worth distinguishing transport failures from protocol violations.

Start in src/advisory/osv-sync.ts at fetchImpl(sourceUrl) and readResponseBytes, then review the existing error gate in network.ts and the protocol checks in src/scanner.ts:208. Reproduce the mid-download socket failure with the local server described in the issue. Done means download failures retain the OSV network hint and context, while protocol violations do not receive that hint; this item is already being handled by the maintainer.