I am currently facing the same issue and think the basic setup we are using is not correct. ActionCable/TurboStreams assumes that you would have a /cable connection before you submit the job.

1. Visit page and connect to /cable
2. Submit form via Turbo (no page reload)
3. Controller returns Turbo replacement for form and starts background job
4. Background job broadcasts update to replace

Another solution might be trigger an initial update when a new connection happens on the server. This could be done with: https://api.rubyonrails.org/classes/ActionCable/Channel/Callbacks.html I believe it could be done with after_subscribe :send_update..., unless: :subscription_rejected?

Lots and lots of people have the same issue it seems by the way:

• https://github.com/hotwired/turbo-rails/issues/498#issuecomment-2125057060 => Use callbacks https://www.reddit.com/r/rails/comments/1ec08jp/how_do_i_solve_race_when_connecting_turbo/ => Use on_connect on the ActionCable::Channel
• https://discuss.hotwired.dev/t/avoiding-a-race-condition-on-initial-subscription-in-turbo-rails/5761/2 => Resend after a couple of seconds
• https://www.reddit.com/r/ruby/comments/lttk0l/turbo_streams_how_to_properly_structure_logic_for/
• https://discuss.hotwired.dev/t/turbo-stream-broadcasts-happening-before-turbo-stream-from-can-establish-websocket-connection-in-system-tests-with-capybara/3710 => Same issue but during testing