[BUG]: http error is unhandled and empty content is returned

[nam-truong-le]

At this location https://github.com/glideapps/quicktype/blob/master/packages/quicktype-core/src/input/io/NodeIO.ts#L43 we should check the HTTP response code.

Issue Type

Reading file from URL

Context (Environment, Version, Language)

N/A

Input Format:
Output Language:

N/A

CLI, npm, or app.quicktype.io:
Version:

Description

For example, when I provide a github token like this in the cli --http-header "Authorization: token $GITHUB_TOKEN" and the token is expired, instead of throwing an error, quicktype generate empty content.

Input Data

Expected Behaviour / Output

The process should fail

Current Behaviour / Output

quicktype generates empty content.

Steps to Reproduce

Use an expired github token to access github raw URL.

Possible Solution

Check HTTP response code.

[schani]

Confirmed reproducible on current master (v23.3.0, 68ecb28).

Root cause: packages/quicktype-core/src/input/io/NodeIO.ts:60-64, readableFromFileOrURL:

const response = await fetch(fileOrURL, {
    headers: parseHeaders(httpHeaders),
});
return defined(response.body) as unknown as Readable;

The fetch result's body is handed straight to the JSON parser with no response.ok/status check at all. Any HTTP error (401/403/404/5xx) whose body happens to be valid JSON is silently treated as legitimate input — quicktype exits 0 and generates types from the error payload. If the error body is plain text or empty, you instead get a misleading "Syntax error in input JSON" with no indication it was actually an HTTP failure.

Reproduced live: a local server returning 401 with a GitHub-style JSON body ({"message":"Bad credentials",...}) makes quicktype emit:

export interface Data {
    message:           string;
    documentation_url: string;
}

and exit 0 — no error surfaced anywhere.

Note for anyone else reproducing this: on Node 18+ the CLI picks up global fetch (undici), and all URL fetches currently crash there with readStream.setEncoding is not a function (undici's body is a web stream, not a Node Readable) — a separate regression that happens to mask this one. I had to delete globalThis.fetch to force the cross-fetch fallback path and get past that crash to reach this bug. Worth its own issue if not already filed.

Assessment

• Severity: medium — no crash, but silently wrong output (or a misleading error) instead of a clear HTTP failure; particularly nasty with auth-token expiry against APIs like GitHub's, since the error body is often valid JSON.
• Difficulty: easy — add if (!response.ok) messageError("MiscReadError", ...) right after the fetch call.

Reproduction

// server.js — simulates an expired-token 401 from a GitHub-style API
const http = require('http');
http.createServer((req, res) => {
  res.writeHead(401, {'Content-Type': 'application/json'});
  res.end('{"message":"Bad credentials","documentation_url":"https://docs.github.com"}');
}).listen(8473, () => console.log('listening'));

node server.js &
node dist/index.js --lang typescript --src http://localhost:8473/data.json --just-types

(On Node 18+, prefix with a small wrapper that does delete globalThis.fetch; before requiring dist/index.js, to route around the separate undici-stream crash and reach this code path.)

---

Posted from a systematic triage sweep of the issue backlog (assisted by Claude); reproduced against a local build of current master.