Fixing flaky system tests when a job broadcasts multiple Turbo Stream updates

General
1

There’s a class of Turbo Stream system test flakiness that connect_turbo_cable_stream_sources doesn’t fix — when the issue isn’t the WebSocket connection timing, but the ActionCable thread pool not flushing before your Capybara assertion runs.

There are actually 2 spots in the ActionCable broadcast call chain that introduce non-determinism in a test environment, in ActionCable::Channel::Streams#worker_pool_stream_handler and ActionCable::SubscriptionAdapter::Async::AsyncSubscriberMap

We wrote up the full diagnosis and a fix (making worker_pool_stream_handler call invoke synchronously) here:

The drop-in spec support file is at: Monkey-patch Rails ActionCable for deterministic behavior in tests · GitHub

Happy to discuss — curious whether others have hit this or found different approaches.

2

can this be patched in rails?

3

Well… can it?

I don’t mind trying to open a PR, but since this is fundamental changing production-grade performant code for deterministic code for testing, I doubted anyone would accept it.

In what part of Rails would such a code change live?