Rescue subscription errors instead of killing WebSocket connection

[bradgessler]

Problem

ActionCable::Connection::Subscriptions::Error (specifically AlreadySubscribedError) can be raised when a client sends a duplicate subscribe command. This is common during Turbo morph/page refresh cycles, where the <turbo-cable-stream-source> element is re-inserted into the DOM and triggers a re-subscribe.

Currently, this exception propagates to the generic rescue => error clause in handle_incoming_websocket, which logs "Abnormal client failure!" and tears down the entire WebSocket connection in the ensure block.

This is especially problematic with the PostgreSQL subscription adapter, where connection teardown removes all LISTEN subscriptions. With rapid reconnect/resubscribe cycles, the LISTEN thread never stays alive long enough to receive NOTIFY broadcasts from other processes (e.g., background job workers), effectively breaking cross-process ActionCable broadcasts.

Fix

Wrap connection.handle_incoming in a targeted rescue ActionCable::Connection::Subscriptions::Error so subscription-level errors are logged as warnings but the WebSocket connection stays alive.

Testing

Observed in production at https://og.plus with:

• Falcon + async-cable + actioncable-next + PostgreSQL adapter
• Separate web and worker processes (Fly.io)
• Turbo page refreshes via broadcasts_refreshes

Before the fix: zero LISTEN connections in pg_stat_activity, broadcasts silently lost.
After the fix: WebSocket connections survive duplicate subscribe attempts, LISTEN stays active, broadcasts delivered.

[samuel-williams-shopify]

@palkan

rails/rails@7a8f26dcff changed this behaviour to raise an exception, but it seems like some adapters legitimately raise this error in some cases. WDYT?

[samuel-williams-shopify]

I think this is better solved upstream, e.g. rails/rails#57504

[palkan]

@bradgessler As a quick workaround, you can add rescue_from AlreadySubscribedError to your base Connection class.

This is common during Turbo morph/page refresh cycles, where the element is re-inserted into the DOM and triggers a re-subscribe.

Or switch to @anycable/web and forget about that 🙂.

@samuel-williams-shopify In general, I think, it worths adding exception handling to the message processing loop (like Rails does that). Maybe, not Exception, but just StandardError. For example, we don't want to drop connection because of ActiveRecord::NotFoundError, right? (We lack a proper mechanism to communicate errors with clients 🤷‍♂️)