Turbo Streams BroadcastJob and ActionCable StreamElement: retry deduplication gap

Direct answers

1. No supported framework-level pattern exists. Rails 7.1–7.3 and Turbo 7.1–7.3 provide no built-in mechanism to make Turbo::Streams::BroadcastJob retries idempotent. Every retry re-broadcasts the identical <turbo-stream> payload to all subscribers.
2. No message-id attribute is honored. The turbo-stream element accepts only the standard Turbo attributes (action, target, targets, template, content). StreamElement processes each payload unconditionally; unknown attributes are ignored.
3. A custom deduplication layer is mandatory for exactly-once semantics. The minimal contract is described below.

Why the gap exists

ActionCable guarantees at-least-once delivery. Missed messages are not replayed on reconnect unless the application implements a catch-up store. BroadcastJob uses retry_on (ActiveJob), which re-enqueues the same job with the same arguments, producing the same turbo-stream XML. Turbo’s client-side processor has no concept of message identity, so it applies every payload it receives.

Idempotent DOM verbs (replace, update) reduce visible duplication but can still flicker. Non-idempotent verbs (append, prepend, before, after, remove) produce duplicate nodes or errors on re-application.

Minimal contract for a custom deduplication layer

To remain compatible with Turbo Native reconnection behavior, a deduplication layer must satisfy:

• Unique identifier per logical broadcast — generate a UUID or a stable hash of the payload (e.g., Digest::SHA256.hexdigest(payload)) at the point the broadcast is first enqueued, not at retry time.
• Short-lived, connection-scoped cache — store the identifier in a cache that survives WebSocket reconnects (Redis with TTL, database table, or client-side sessionStorage keyed by user + stream name). TTL should cover typical reconnect windows (30–60 s).
• Atomic check-and-set — on each broadcast (server) or receipt (client), atomically check if the identifier exists; if yes, skip processing; if no, store it and proceed.
• Idempotent application — the underlying DOM operation must leave the DOM unchanged after the first application. Prefer replace/update; if append/prepend are required, the deduplication layer must suppress the duplicate entirely.

Verification steps

1. Enqueue a BroadcastJob with retry_on StandardError, attempts: 3 that performs an append action. Confirm duplicate DOM nodes appear after the first retry.
2. Add a data-turbo-message-id attribute to the turbo-stream payload (unknown attributes are ignored by the parser) and implement a server-side Redis SETNX check before Turbo::StreamsChannel.broadcast_action_to. Re-run; verify the second retry is skipped and the DOM remains unchanged.
3. Simulate a reconnect: close the WebSocket, wait for the client to re-subscribe, and confirm the cached identifier prevents re-application.

Assumptions and uncertainty

• Research reflects Rails/Turbo behavior up to 2026-11-13; newer releases may add native support — verify against your exact versions.
• Client-side deduplication in sessionStorage works for Turbo Native but requires coordination with the native bridge to persist across app backgrounding.
• Race conditions between parallel retries need atomic cache operations (Redis SETNX or DB unique constraint).

One missing diagnostic detail

Which DOM verb (replace, append, etc.) does your failing broadcast use? The answer changes whether flicker (idempotent verb) or duplicate nodes (non-idempotent verb) is the primary symptom, and whether a client-only sessionStorage dedup is sufficient or a server-side gate is required.