docs: correct the built-in retry behaviour in the supabase-js retry guide

The "Built-in retries for PostgREST queries" section described behaviour
that supabase-js does not have.

It said POST requests are retried. RETRYABLE_METHODS is GET, HEAD and
OPTIONS, and shouldRetry returns false for anything outside that list, so
a write is never replayed. This was the most consequential of the errors,
because it invites a reader to skip their own handling for failed writes.

It listed 408, 409, 503 and 504 as the retried statuses. The actual list
is RETRYABLE_STATUS_CODES, which holds 520 and 503.

It described the backoff as exponential with jitter. getRetryDelay is
Math.min(1000 * 2 ** attemptIndex, 30000), which has no random component.

Also noted that .rpc() sends POST unless called with { get: true }, so
RPC calls are not covered by the built-in retries despite the intro
listing .rpc() alongside .from().

Corrections only. The page structure and the fetch-retry section are
unchanged.
This commit is contained in:
KrisDevX authored and Katerina Skroumpelou committed 2026-10-01 13:15:55 +03:00
1 parent 4f0be099e7
commit 66ed5b3a95
1 file changed
+4 -2
@@ -12,9 +12,11 @@ You should only enable retries if your requests fail with network errors (e.g. 5
## Built-in retries for PostgREST queries
Starting with `supabase-js` v2.102.0, PostgREST queries (`.from()`, `.rpc()`) include built-in automatic retries for transient errors. Retries are **enabled by default** and use exponential backoff with jitter.
Starting with `supabase-js` v2.102.0, PostgREST queries (`.from()`, `.rpc()`) include built-in automatic retries for transient errors. Retries are **enabled by default** and use exponential backoff.
Retryable errors include HTTP status codes 408 (Request Timeout), 409 (Conflict), 503 (Service Unavailable), and 504 (Gateway Timeout), as well as network failures. Only idempotent HTTP methods (GET, HEAD, OPTIONS) and POST requests (used by PostgREST) are retried.
`supabase-js` retries only idempotent HTTP methods: GET, HEAD, and OPTIONS. It doesn't retry POST, PATCH, PUT, or DELETE, so a write is never sent twice. For the methods it does retry, it retries on HTTP status codes 503 Service Unavailable and 520 Unknown Error, and on network failures.
Because `.rpc()` sends POST by default, RPC calls aren't retried. Call them with `{ get: true }` if you want the built-in retries to apply.
### Disable built-in retries