Skip to content

fix(realtime): reset channel state on phx_error#1109

Open
AndroidPoet wants to merge 1 commit into
supabase:mainfrom
AndroidPoet:fix/realtime-channel-error-resets-state
Open

fix(realtime): reset channel state on phx_error#1109
AndroidPoet wants to merge 1 commit into
supabase:mainfrom
AndroidPoet:fix/realtime-channel-error-resets-state

Conversation

@AndroidPoet

Copy link
Copy Markdown
Contributor

Problem

When a subscribed channel receives a phx_error frame (a channel-level error the server sends without closing the socket, for example a replication error or an authorization change), onMessage only logs it. The channel stays .subscribed even though it is dead server-side, so status never reflects the error and observers keep waiting for events that never arrive. During a subscribe attempt a phx_error is likewise ignored, so the join waits out the full timeout instead of failing fast.

realtime-js treats phx_error as a channel error and drops the channel so it can rejoin.

Fix

Route .error through the existing didReceiveClose(), the same reset the .close case uses. Its own doc already covers this case ("phx_close or system error that should drop the channel"): it clears the join ref and pending pushes and moves the channel to .unsubscribed. The channel stays registered on the socket, so it rejoins on the next reconnect.

If you would prefer the channel to also schedule an immediate per-channel rejoin (as realtime-js does) rather than waiting for the next socket reconnect, I am happy to add that.

Tests

Added testChannelErrorResetsSubscribedStatus: drives a channel to .subscribed over a fake socket, sends a phx_error frame, and asserts the channel transitions to .unsubscribed. It fails before this change (the channel stays .subscribed) and passes after. Full RealtimeTests suite passes (241 tests). No public API change.

@AndroidPoet AndroidPoet requested review from a team and grdsdev as code owners July 9, 2026 19:46
@coveralls

Copy link
Copy Markdown

Coverage Report for CI Build 29045564135

Coverage increased (+0.03%) to 83.519%

Details

  • Coverage increased (+0.03%) from the base build.
  • Patch coverage: 1 of 1 lines across 1 file are fully covered (100%).
  • No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.


Coverage Stats

Coverage Status
Relevant Lines: 9508
Covered Lines: 7941
Line Coverage: 83.52%
Coverage Strength: 38.06 hits per line

💛 - Coveralls

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants