Reliable streams and turbo_stream_from

[luizpvas]

Hey guys, how is it going? I'm testing Anycable's reliable streams in a Rails app and want to make sure I have the right mental model here.

Let's say we have two pages with different turbo_stream_from sources. As we navigate between those pages we subscribe and unsubscribe from each Turbo::StreamsChannel. With reliable streams enabled (createCable({ protocol: "actioncable-v1-ext-json" })), the payload includes history.since, which is working as expected.

Problem: if the content on page A changes while we're on page B, and that change was broadcasted with an append action, page A will end up with duplicated items on the next visit. One from the fresh render and another from reliable stream's confirm history synchronization.

Is this the expected behavior, even though the websocket stayed connected during the navigation? I can provide a sample application if it helps showcase what I described.

Env: the rails app uses both anycable-rails and anycable-rails-jwt, RPC-less setup (--jwt_id_key and --turbo_rails_key passed to anycable-go), redisx broadcast adapter and memory broker.

[palkan]

Hey!

One from the fresh render and another from reliable stream's confirm history synchronization.

What do you mean by fresh render?

It would be great to see more WS messages (sent and received) right before you observe duplication. (You can also enable debug logs: createCable({logLevel: 'debug', ... })).

In theory, receiving the same message twice is possible when requesting history, though the chances are low. We do not de-dup messages at the protocol/client level (though that's something we consider to add in the future). We recommend handling duplicates at the application level; for example, Turbo Streams do that for you if you use IDs. i.e., the append action takes care of adding an element with the same ID once.

[luizpvas]

Hey there, thanks for the answer!

What do you mean by fresh render?

Normal page render from Rails that already includes the broadcasted item.

I recorded a short video with the example I described in the comment above with logLevel: debug: https://github.com/anycable/anycable/assets/4276593/172ef873-5449-4ab7-9db0-89cde031b35c
Gist with the source: https://gist.github.com/luizpvas/eb06be3334c4ef8232ed5f9d156062e0
And the log output: https://gist.github.com/luizpvas/db6713f08d5ba0bf295d0015f41be94d

---

Adding a unique ID to the element does indeed fix duplicated DOM elements, thanks for pointing that out. I guess what got me confused was that technically the user leaves and then rejoins the channel when visiting the page again. It just happens that history synchronization is triggered with the latest state already on the page (if I understood it correctly).

[palkan]

Normal page render from Rails that already includes the broadcasted item.

I see; that's a different problem, since there are two sources of truth (the stream and a HTTP response).

technically the user leaves and then rejoins the channel when visiting the page again

Yeah; and since the latest broadcast hasn't been received synchronously (it could arrive within the unsubscribe-subscribe gap, for example), it's loaded via a history request. And the cable has no idea of the item added on the page via HTTP.