[irisfield]

What kind of change does this PR introduce?

Bug fix

What is the current behavior?

Fixes #540

postgrestRequest and the /spec resource parse every response as JSON without checking the status. A PostgREST error body is returned as a normal result with isError unset, and an empty or non-JSON body throws a SyntaxError that hides the status.

What is the new behavior?

Both go through a readJsonBody helper. It throws PostgREST <status>: <body> when response.ok is false, with statusText in place of an empty body and no suffix when both are empty. A successful body that is not JSON throws PostgREST <status>: expected JSON, got <content-type>: <first 200 characters>. postgrestRequest returns { result: null } for an empty successful body (204).

call	before	after
GET /no_such_table?select=*	isError: false, {"result":{"code":"PGRST205",…}}	isError: true, PostgREST 404: {"code":"PGRST205",…}
GET /no_such_table?select=*&bad=	isError: false, {"result":{"code":"PGRST100",…}}	isError: true, PostgREST 400: {"code":"PGRST100",…}
GET / with an invalid --apiKey	isError: false, {"result":{"message":"Invalid API key",…}}	isError: true, PostgREST 401: {"message":"Invalid API key",…}
200 JSON	{"result":…}	same

No change to tool names, descriptions, or input and output schemas.

How to Review

1. Status check

   • packages/mcp-server-postgrest/src/server.ts
   • The /spec resource read and postgrestRequest both call readJsonBody, which holds the status check and the JSON parse.

2. Tests

   • packages/mcp-server-postgrest/src/server.http-errors.test.ts
   • Calls postgrestRequest and reads the /spec resource against a local http stub: a 400 PostgREST error, a 500 HTML body, a 200 JSON body, a 204, a 200 HTML body and an empty 404. It does not need the local Supabase stack that server.test.ts uses.

Verification

• With the fix removed, the 400 JSON, 500 HTML and 204 tests fail, and the 200 JSON test passes.
• npx vitest run src/server.http-errors.test.ts: 8 passed. npx tsc --noEmit and pnpm format:check: clean.
• On a hosted project, running the built package over stdio: before, the three calls in the table return isError: false. After, they return isError: true with 404, 400 and 401.

[mangeshraut712]

Reading the body as text, checking response.ok first and parsing afterwards is the right shape, and the 204 → { result: null } case is a nice catch now that prefer: return=representation isn't always honoured. Two small follow-ups below.

[mangeshraut712]

The issue's second symptom ("a non-JSON body throws a SyntaxError that hides the status") is fixed for error statuses, but it can still happen on 2xx. A common example is a wrong apiUrl that points at something returning a 200 HTML page (a dashboard, a proxy splash page, a trailing /rest/v1 missing). JSON.parse(text) then throws Unexpected token '<' with no status or URL. Wrapping the parse would make that case as debuggable as the error-status one, e.g.:

let parsed: unknown;
try { parsed = JSON.parse(text); }
catch { throw new Error(`PostgREST ${response.status}: expected JSON, got ${response.headers.get('content-type') ?? 'unknown content-type'}: ${text.slice(0, 200)}`); }

The same applies to JSON.parse(text) in the /spec read above (L64).

[mangeshraut712]

The new test file only exercises postgrestRequest; the /spec resource's error path isn't covered. The stub's fallback (404, empty body) would make an easy case via client.readResource({ uri: 'postgrest:///spec' }) (or whatever URI resources('postgrest', …) generates). That would also show what an empty error body looks like: currently it's PostgREST 404: with nothing after the colon, so appending response.statusText when text is empty might be friendlier.

[irisfield]

Thanks for the review. Both are in 8b13e06: a successful body that is not JSON now reports its status and content type, for the tool and for /spec, and an error with an empty body reads PostgREST 404 (with statusText when there is one). The /spec error path now has tests; they check the raw server response, because the client rejects the resource error as an invalid result.