I'm working on an app that uses Turbo 8 through version 2.0.0-beta.2 of turbo-rails.

I've noticed that if a page contains multiple <turbo-cable-stream-source> elements, all with the same signed-stream-name, via multiple calls to turbo_stream_from(foo), refreshes on foo are duplicated, leading to request multiplication for every refresh event.

For example, with 5 copies of the same <turbo-cable-stream-source>, there are 5 subscription requests (shown highlighted below in green), and 1 subscription confirmation (shown below, not highlighted):

(Relatedly, rails/rails#44652 seems to imply that there would be constantly repeated subscription attempts for the N-1 subscriptions? But I don't see that behavior.)

Then, when there is a refresh from an update! on the relevant model (configured with broadcasts_refreshes), the server sends a single websockets message for "<turbo-stream action=\"refresh\"></turbo-stream>" (not 5 of them), and the client initiates 5 requests, 4 of which are canceled:

Although the requests are canceled, the requests may still result in server work, which cumulatively results in a lot of wasteful work, particularly if the endpoints are expensive.

It seems surprising to me that N copies of <turbo-cable-stream-source> all with the same signed-stream-name leads to multiple requests, particularly given that they're auto-cancelled.

Moreover, working around the duplication problem feels like it introduces a lot of complexity: it becomes necessary to track which pages have which subscriptions and for what purpose.

For example, consider a simple model that uses Turbo 8:

class Patient < ApplicationRecord
  broadcasts_refreshes
end

Then suppose there are some related partials:

# _abc.html.erb partial

<%= turbo_stream_from patient %>

<%# ... %>

# _xyz.html.erb partial

<%= turbo_stream_from patient %>

<%# ... %>

In my case, the abc and xyz partials are relatively complex and may appear in different contexts across different pages. The intention is to make sure that using either of these partials results in Turbo-powered updates, hence the embedded turbo_stream_from patient directly into the partials themselves.

However, if a page happens to use both abc and xyz partials, Turbo refresh requests are doubled. With N partials, there are effectively N copies of the subscription.

To avoid that duplication, a developer has to track which pages use abc, or xyz, or both, and then make sure that the relevant turbo_stream_from subscriptions are set up only once, at level of abstraction higher than the partial.

I only just recently started using Turbo, but this behavior feels like it's a bug. It's also interesting that the client is apparently happy with only 1 subscription confirmation from the server, yet that single subscription confirmation still results in N requests. Perhaps that points to the cause of the problem.