22 lines
2.5 KiB
Markdown
22 lines
2.5 KiB
Markdown
# Recover login when the API proxy returns no data
|
|
|
|
The API proxy intermittently returned HTTP 200 with an empty HTML response for authentication and workspace membership requests. The same Supabase backend returned a valid session and the existing workspace directly. The former membership loader treated malformed responses like missing workspaces, while an existing login gate kept its loading message. A second authentication client used by the fallback also shared the same session storage key.
|
|
|
|
The shared transport now validates JSON responses and uses the same backend directly for failed reads and password login. Authorization and the single SDK session are preserved. Only GET/HEAD and explicitly allowlisted read RPCs can be retried, plus password login. Database writes are not replayed. Both channels have bounded waits; permission and credential errors are returned without fallback.
|
|
|
|
Membership requests for the same account share one in-flight operation. Late responses from a different account are ignored. Missing RPC compatibility is used only for a missing function, not network errors. A failed membership request produces a retry/exit screen and cannot be mistaken for a developer account with no company. Successful login still opens the normal application.
|
|
|
|
Regression coverage includes empty/invalid proxy responses, identical request bodies and authorization on fallback, non-replayed writes, credential rejection, concurrent membership loads, recovery UI, and a real Supabase SDK login against controlled endpoint responses. The full flow is checked on desktop and mobile without changing production credentials or authentication requirements.
|
|
# Server retry loop discovered during production verification
|
|
|
|
Supabase logs showed PostgREST 14.5 repeatedly executing
|
|
`sun_v17_save_client_v1772` with `SUN_CLIENT_CONFLICT expected=1 actual=2`,
|
|
SQLSTATE `40001`, exhausting the REST connection pool. Both direct and proxied
|
|
workspace reads then timed out. See the [Supabase incident guidance](https://supabase.com/docs/guides/troubleshooting/high-cpu-and-infinite-transaction-retries-when-using-custom-error-codes-in-rpc-functions-77326b).
|
|
|
|
Migration `20260918000000_conflict_http_status.sql` changes the two application
|
|
version-conflict handlers to `PT409`. It preserves function bodies, privileges,
|
|
revision checks and data. Existing looping backends must be identified in this
|
|
project's logs and `pg_stat_activity`, then terminated individually. The SQL smoke
|
|
test verifies both conflicts return `PT409` and stale writes leave data unchanged.
|