Draining the Refresh Broadcast debouncer?

[bensheldon]

If I have a short-lived Rails Runner script that calls broadcast_refresh_later_to, it won't get emitted because the script will end before the debouncer's scheduled task hits its delay.

turbo-rails/app/channels/turbo/streams/broadcasts.rb

Lines 73 to 75 in cb47713

	refresh_debouncer_for(*streamables, request_id: request_id).debounce do
	Turbo::Streams::BroadcastStreamJob.perform_later stream_name, content: turbo_stream_refresh_tag(request_id: request_id, **opts).to_str # Sidekiq requires job arguments to be valid JSON types, such as String
	end

My workaround is to do this at the end of my script, but it's not my favorite:

sleep Turbo::Debouncer::DEFAULT_DELAY + 0.1

It might be nice to keep an Weakmap or something of all of the Turbo::Debounce instances to do something more elegant than sleep (like rescheduling the ScheduledTask to now). I guess I could grab them out of ObjectSpace too. Mostly flagging this as a weird edge case cause I was real confused for 15 minutes till I discovered the cause.

[bensheldon]

Thinking about this some more, I think a more Railsy way to architect this would be to put the ThreadDebouncer in the execution context (rather than current thread) and then drain it automatically in the execution finisher.

[bensheldon]

I discovered that this was causing deadlocks and flakey test failures in an application. A stacktrace is in here:

bensheldon/good_job#1637 (comment)

I saw this manifest in warnings like:

• WARNING: SAVEPOINT active_record_1 does not exist
• WARNING: there is already a transaction in progress

This is how I'm disabling it in a test support file:

# frozen_string_literal: true
# The Turbo debouncer causes threads to run in the background
# which can break transactional tests. Disable it.
module DisableTurboDebouncer
  def debounce(&block)
    block.call # rubocop:disable Performance/RedundantBlockCall
  end
end
Turbo::Debouncer.prepend(DisableTurboDebouncer)

[excid3]

I ran into this today too. I was adding a simple test to ensure broadcasts_refreshes_to worked and had the same situation. Adding the sleep or disabling the debouncer with the module works.

class Todo
  belongs_to :project
  broadcasts_refreshes_to :project
end

class TodoTest < ActiveSupport::TestCase
  include ActiveJob::TestHelper

  test "broadcasts refreshes" do
    project = projects(:one)
    project.todos.create!(name: "example", user: users(:one))
    sleep Turbo::Debouncer::DEFAULT_DELAY + 0.1
    perform_enqueued_jobs
    assert_turbo_stream_broadcasts project, count: 1
  end
end

[jorgemanrubia]

Hey I had never ran into this need, but it certainly looks like we should do a better job here.

Thinking about this some more, I think a more Railsy way to architect this would be to put the ThreadDebouncer in the execution context (rather than current thread) and then drain it automatically in the execution finisher.

+1 to the approach. I'll be happy to merge if you want to prepare a PR.

Not a great solution, but in the turbo-rails test I used this, which is better than an active sleep:

turbo-rails/test/streams/streams_channel_test.rb

Line 177 in 1428954

Turbo::StreamsChannel.refresh_debouncer_for("stream").wait