🟡 Severity: MEDIUM

This deferred callback has no lifecycle guard. If application code unsubscribes/removes a channel while auth is pending (e.g. during logout), the callback still reaches channelAdapter.subscribe() and emits phx_join after the channel was closed/removed. A private channel can therefore be re-established and receive protected realtime traffic after the caller revoked it.
Helpful? Add 👍 / 👎

Suggestion: Add a lifecycle guard to the deferred sendJoin callback so that if the channel has been unsubscribed or removed while the auth promise was pending, the join is not attempted. Wrap both .then() callbacks with a check that the channel is still in closed state before calling sendJoin. A channel that has been intentionally unsubscribed will transition away from closed (to leaving), so this guard prevents re-joining a revoked private channel.

⚠️ Experimental Feature: This code suggestion is automatically generated. Please review carefully.

Confirmed, and the guard is needed — but isClosed() is not the predicate that separates the two cases.

I wrote the scenario as two tests, unsubscribe() and removeChannel() while the auth promise is still pending. Both fail on this branch as it stood: phx_join is sent for a channel the caller already left.

Then I applied the suggestion verbatim and re-ran them. Both still fail. phoenix's leave() puts a channel that never joined straight back into closed:

// @supabase/phoenix 0.4.5 — assets/js/phoenix/channel.js:238
leave(timeout = this.timeout){
  this.state = CHANNEL_STATES.leaving
  let onClose = () => { this.trigger(CHANNEL_EVENTS.close, "leave") }
  let leavePush = new Push(this, CHANNEL_EVENTS.leave, closure({}), timeout)
  leavePush.receive("ok", () => onClose()).receive("timeout", () => onClose())
  leavePush.send()
  if(!this.canPush()){ leavePush.trigger("ok", {}) }   // <- runs synchronously here
  return leavePush
}

canPush() is socket.isConnected() && isJoined(), false for a channel that never joined, so leavePush.trigger("ok", {}) fires in the same tick, and the close handler sets state = closed and removes the channel from the socket (channel.js:62-70). removeChannel() goes further and calls teardown(), which sets closed again (channel.js:112-119).

So by the time the deferred callback runs, isClosed() is true both for a channel that was never subscribed and for one the caller just left. The guard would let the join through in exactly the case it is meant to block.

What separates them is intent, not state, so I track it explicitly: a _leaveRequested flag set in unsubscribe() and teardown() and checked before the deferred sendJoin(). The synchronous path is untouched.

Both tests pass with that. Full realtime-js suite: 480 passed, 1 skipped, 27 files. tsc --noEmit and prettier --check clean.

One limit worth stating: calling subscribe() again on the same channel object after leaving it still behaves differently on the two paths. The synchronous path throws phoenix's tried to join multiple times; the deferred one does not. That gap is not introduced here (on the previous commit the deferred path silently joined instead), and closing it means teaching subscribe() about a pending deferred join, which is a wider change than this PR is making. Happy to take it on if you would rather have it in the same PR.