Turbo Streams 7.2: silent ignore on missing targets – should we add fail_on_missing?

Question

Unresolved behavior
The current Turbo Streams implementation in Rails 7.2 silently ignores actions whose target attribute does not match an element in the client DOM. No error is thrown, and the page remains unchanged.
Developers face a design decision: continue relying on this silent‑ignore semantics or implement a new configuration that raises an error or triggers a callback when a target is missing. The lack of an official option forces teams to add custom checks in JavaScript or server logs, complicating integration tests that mock WebSocket or SSE streams.
Key constraints include backward compatibility with existing production deployments, the need for deterministic test outcomes, and the absence of a documented change‑log entry that clarifies whether silent ignore is intended to persist.
What are the trade‑offs of maintaining silent ignore versus providing a fail‑on‑missing mode? How would a new configuration affect existing Turbo Streams payloads and client‑side listeners? What testing strategies can reliably surface missing‑target issues in a production‑like environment?

Siddharth · Answer

Direct answer
Do not add fail_on_missing to Turbo Streams core. Preserve silent ignore as the default and detect missing targets through system-test assertions and development-time logging instead.

Confirmed behavior vs. likely intent
In Rails 7.2 with the current Hotwire Turbo release, a stream action whose target does not match a DOM element is silently discarded: no error is thrown and the page is unchanged. This is the confirmed, observable behavior.
The likely explanation is graceful degradation. In live UIs, elements can disappear between broadcast and render—another user removes a row, or a competing stream action deletes the node. Failing hard would convert benign races into broken pages.

Trade-offs of a strict mode

Backward compatibility: Production apps already depend on silent ignore. A strict default would break them the first time a stale target is broadcast.
False positives: Missing targets are not always defects. Pagination, optimistic removal, and conditional rendering can legitimately target absent nodes.
Payload and listener impact: The wire format would not change, but every client would need a new configuration surface. Existing custom listeners would have to distinguish intentional races from bugs.

Detection without core changes

System tests: Use Rails system tests to assert the expected DOM state after a broadcast. If the target is absent, the assertion fails naturally without any new config.
Development instrumentation: In non-production environments, wrap Turbo Stream rendering to log missing target IDs. Log, do not raise.
Server-side guards: For critical updates, verify the target ID is present in the current user’s rendered HTML before broadcasting.

When strictness helps
A scoped, opt-in strict mode can speed up debugging in greenfield apps where races are impossible and every target is guaranteed. Even then, implement it as an application-level test helper or middleware, not as a Turbo core default.

Verification note
This guidance reflects documented Turbo Streams behavior and its design philosophy. Because Turbo ships independently of Rails, confirm the exact target-resolution logic in the JavaScript version pinned by your application before finalizing a long-term strategy.

Turbo Streams 7.2: silent ignore on missing targets – should we add fail_on_missing?

Unresolved behavior

1 answer

Direct answer

Confirmed behavior vs. likely intent

Trade-offs of a strict mode

Detection without core changes

When strictness helps

Verification note

Your perspective belongs here.

0 question comments