I found that recording a valid JSON null response changes its value in the fixture. The live recording returns null, but replay returns the string "null". Connector hooks can therefore see different types between the recorded call and the replay test.
Save this as repro-record-null.ts at the repository root and run deno run --allow-read --allow-env repro-record-null.ts with Deno 2. It uses a local stub, with no credentials or network:
import {recordingFetch,replayFetch,type RecordedCall} from './shared/testing/fixtures.ts';
const calls:RecordedCall[]=[];
const response=await recordingFetch(()=>Promise.resolve(new Response('null',{headers:{'content-type':'application/json'}})),calls)('https://api.test/value');
console.log('recorded live:',await response.json());
console.log('stored:',JSON.stringify(calls[0].res.body),typeof calls[0].res.body);
const replayed=await replayFetch({name:'null',description:'JSON null response',calls})('https://api.test/value');
const body=await replayed.json();
console.log('replayed:',JSON.stringify(body),typeof body);Observed:
recorded live: null
stored: "null" string
replayed: "null" stringI expect the stored and replayed values to be JSON null, matching the live response. A vendor response containing the JSON string "null" must remain a string.
In recordingFetch, parseMaybeJson(text) ?? text falls back for a successfully parsed null as well as for a parse failure. I propose checking explicitly for undefined, which is the parse-failure sentinel. Regression coverage should exercise null, the string "null", other JSON scalars, nested nulls, and non-JSON text through recording and replay.
I searched open and closed issues/PRs for recordingFetch and JSON-null recording. The no-content status fix in #199 and engine consolidate-output fixes concern different paths; this reproduces with an ordinary 200 response.
Activity
0No activity yet.