Skip to content

Inbox can go silently stale: missed refresh broadcasts have no recovery path #1

Description

@rameerez

Found auditing CarHey production (Hotwire-Native app on the RailsFast template) ahead of RailsFast v1.0.0.

The gap

app/views/chats/conversations/index.html.erb subscribes with a bare turbo_stream_from chats_current_messager, :chats_inbox and relies on refresh broadcasts for updates. Two loss modes make that subscription silently stale:

  1. Non-replayable transport: Action Cable / Solid Cable does not replay frames. Any refresh broadcast sent while the client's socket is down (sleep, network blip, backgrounded WebView) is gone forever. This bites hardest on Hotwire Native, where an inbox tab's WebView lives for the whole app session with pull-to-refresh often disabled — a missed frame means the inbox is stale until the user happens to navigate.
  2. Non-durable debounce: broadcast_refresh_later_to parks the refresh in Turbo::Debouncer's in-process 0.5s ScheduledTask before the durable job enqueue — a process restart in that window drops the broadcast server-side.

Downstream heal (reference implementation)

CarHey PR #75 wraps the gem's inbox subscription in a stream-reconciler Stimulus controller in recovery-only mode (no polling): it refetches the frame on cable reconnect, foreground-after-hidden, and network-online, debounced. The RailsFast template ships the same primitive as railsfast--turbo--stream-reconciler (interval 0 = recovery-only).

Suggestion

Either ship an equivalent self-contained recovery affordance in the gem's inbox view (so every host app gets it), or document the wrap pattern prominently for Hotwire Native hosts. Happy to upstream the reconciler pattern if useful.

🤖 Generated with Claude Code

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions