fix(auth): preserve 5xx error message

[7ttp]

TL;DR:

handleError threw retryable 5xx errors before reading the response body, so every server error surfaced as message: "{}".

Parse the body first, keep the NETWORK_ERROR_CODES classification
a 5xx with a JSON body now carries the server's message, a body-less 5xx
(gateway HTML page) throws exactly what it did before.
Error class and status unchanged on every path.

ref:

• closes auth-js: handleError discards the response body for 5xx, so every server error reports message: "{}" (regression in 2.108.2) #2585

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 5de4d749-07f3-48da-a53c-ae008eaf32f6

📥 Commits

Reviewing files that changed from the base of the PR and between d5173a3 and 45e4e2a.

📒 Files selected for processing (2)

• packages/core/auth-js/src/lib/fetch.ts
• packages/core/auth-js/test/fetch.test.ts

🚧 Files skipped from review as they are similar to previous changes (2)

• packages/core/auth-js/src/lib/fetch.ts
• packages/core/auth-js/test/fetch.test.ts

---

📝 Walkthrough

Summary by CodeRabbit

• Bug Fixes
  • Improved handling of server and network errors.
  • Retryable errors now preserve meaningful messages returned in valid JSON responses.
  • Non-JSON server errors continue to display their HTTP status appropriately.
  • Network failures now provide clearer fallback messages using available status information when a response cannot be parsed.

Walkthrough

handleError now parses fetch response bodies before classifying network error statuses. JSON 5xx responses provide their parsed server message to AuthRetryableFetchError. Unparseable 5xx responses remain retryable and use status text or an HTTP status fallback. Other parsing failures continue to produce AuthUnknownError. Tests cover JSON 500 responses and non-JSON 502 responses.

Assessment against linked issues

Objective	Addressed	Explanation
Preserve server-provided messages for retryable 5xx responses [#2585]	✅
Keep non-JSON 5xx responses classified as retryable [#2585]	✅

Suggested labels: auth-js

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[pkg-pr-new]

Open in StackBlitz

@supabase/auth-js

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

@supabase/functions-js

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

@supabase/postgrest-js

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

@supabase/realtime-js

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

@supabase/storage-js

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

@supabase/supabase-js

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

commit: 0986666

[coveralls]

coverage: 73.518% (-7.9%) from 81.419% — 7ttp:fix/auth-handle-error-preserve-5xx-body into supabase:master

[mandarini]

This is a clean fix, thanks!! :D Two small things before I merge:

1. In the catch branch you still pass the Response to _getErrorMessage, so a body-less 5xx keeps reporting "{}". Since that is the whole complaint in the issue, could we use error.statusText || \HTTP ${error.status}`there? The fallback matters because HTTP/2 has no reason phrase, sostatusText` is often an empty string behind the edge.

2. Both tests use the msg body shape, which is the pre-2024-01-01 format. The client sends the 2024-01-01 API version header by default, and against that the server replies with {"code": "unexpected_failure", "message": "..."} instead. Your fix handles both, since _getErrorMessage checks msg and message, but it would be good to cover the shape that actually ships. There is already a 'with API version 2024-01-01 and error code' entry in the handleError table you could mirror.