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 🤷‍♂️)

[bradgessler]

This is huge! Thanks for all who landed it!

@palkan I actually gave up on ActionCable because it doesn't really have a protocol and drops messages 🤣

A few months ago I finally got mad at ActionCable & SoildCable for quietly dropping message and built out v2 of https://github.com/firehoseio/next instead (I built v1 almost 15 years ago!) using @ioquatix's async-web-socket library. I have a weird thing where I want the lease number of moving parts possible in my envs, and this was the most minimal thing I could think of since it runs on Postgres and doesn't require running any additional processes. It's running at https://opengraphplus.com if you want to see it in action. AnyCable is great, but I had the curse of knowledge of Firehose v1 and wanted less moving parts than AnyCable.

I still can't believe how much stuff runs on straight-up ActionCable without any protocol for detecting dropped messages.