# Fixing flaky system tests when a job broadcasts multiple Turbo Stream updates
**URL:** https://discuss.hotwired.dev/t/fixing-flaky-system-tests-when-a-job-broadcasts-multiple-turbo-stream-updates/6423
**Category:** General
**Created:** [March 20, 2026, 2:27pm UTC](https://discuss.hotwired.dev/t/fixing-flaky-system-tests-when-a-job-broadcasts-multiple-turbo-stream-updates/6423 "2026-03-20T14:27:26Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@gpassero](https://discuss.hotwired.dev/u/gpassero)
#### Post date: [March 20, 2026, 2:27pm UTC](https://discuss.hotwired.dev/t/fixing-flaky-system-tests-when-a-job-broadcasts-multiple-turbo-stream-updates/6423/1 "2026-03-20T14:27:26Z")
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:
> **[Fixing a stubborn class of flaky Turbo Stream system tests](https://dev.to/gpassero/fixing-a-stubborn-class-of-flaky-turbo-stream-system-tests-1lpa)**
>
> If you've written system tests against a Rails app that uses Turbo Streams, you've probably hit this:...
The drop-in spec support file is at: [Monkey-patch Rails ActionCable for deterministic behavior in tests · GitHub](https://gist.github.com/gap777/6cc10654606e8ed27c7d1105b9d9eca5)
Happy to discuss — curious whether others have hit this or found different approaches.
---
### Author:  [@birdybird](https://discuss.hotwired.dev/u/birdybird)
#### Post date: [July 11, 2026, 3:58am UTC](https://discuss.hotwired.dev/t/fixing-flaky-system-tests-when-a-job-broadcasts-multiple-turbo-stream-updates/6423/2 "2026-07-11T03:58:40Z")
can this be patched in rails?
---
### Author:  [@gpassero](https://discuss.hotwired.dev/u/gpassero)
#### Post date: [July 13, 2026, 12:16pm UTC](https://discuss.hotwired.dev/t/fixing-flaky-system-tests-when-a-job-broadcasts-multiple-turbo-stream-updates/6423/3 "2026-07-13T12:16:37Z")
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?