fix(postgrest): pass request headers as plain object for RN/custom-fetch compatibility

[mandarini]

Summary

Passes request headers to the user-supplied fetch as a plain object instead of a Headers instance. Picks up the intent of #2017 from @dev-hari-prasad with a minimal, focused change.

Why

React Native's XHR-based fetch polyfill (whatwg-fetch) silently drops headers — most notably Content-Type — when given a Headers instance. Without Content-Type: application/json, PostgREST cannot parse the JSON body, and a parameter-less rpc() call surfaces as a confusing PGRST202 ("Searched for the function with a single unnamed text parameter").

See:

• supabase-js rpc() fails with PGRST202 for parameter-less functions in React Native #1562 (the original bug report)
• header not sent by fetch facebook/react-native#33933 (upstream RN tracking issue)

Alignment with sibling packages

The sibling clients have always handled headers as plain objects internally and at the fetch call site:

• auth-js — src/lib/fetch.ts spreads { 'Content-Type': '...', ...options?.headers } into request params.
• storage-js — BaseApiClient.headers: { [key: string]: string }.
• functions-js — FunctionsClient.headers: Record<string, string>.

postgrest-js was the outlier: a previous refactor (postgrest-js#619, "chore: refactor in favor of Headers API") moved it to wrap headers in new Headers(...) at the fetch boundary, primarily to get ergonomic multi-value handling for the Prefer header.

This PR keeps that ergonomic win — the internal this.headers storage stays a Headers instance, so Prefer append-style construction continues to work as designed — and only flattens to a plain object at the moment of the _fetch() call. Wire-level behavior to PostgREST is unchanged on standard runtimes (native fetch normalizes either form); the change only affects what user-supplied fetch wrappers see.

Behavior note for custom fetch consumers

Headers handed to a user-supplied fetch are now a plain Record<string, string> with lowercase keys (per Headers.prototype.forEach semantics). Wrappers that previously did req.headers.get('Content-Type') should switch to req.headers['content-type'].

Tests

• New: test/headers-serialization.test.ts — asserts the request handed to a custom fetch has content-type: application/json reachable by plain-object key access (i.e. what the RN polyfill would see).
• Updated: test/fetch-errors.test.ts, test/retry.test.ts, test/basic.test.ts to reflect the plain-object shape on the wire.

Closes #1562.

[pkg-pr-new]

Open in StackBlitz

@supabase/auth-js

npm i https://pkg.pr.new/@supabase/auth-js@2414

@supabase/functions-js

npm i https://pkg.pr.new/@supabase/functions-js@2414

@supabase/postgrest-js

npm i https://pkg.pr.new/@supabase/postgrest-js@2414

@supabase/realtime-js

npm i https://pkg.pr.new/@supabase/realtime-js@2414

@supabase/storage-js

npm i https://pkg.pr.new/@supabase/storage-js@2414

@supabase/supabase-js

npm i https://pkg.pr.new/@supabase/supabase-js@2414

commit: eca699f