[Bug] iOS: open thread does not show live replies until the user sends

[Mduffield101]

Describe the bug

On Buzz Mobile for iOS, a reply that arrives while its thread is already open is stored by the relay but does not appear in the thread UI. Agent Activity updates, confirming the phone is receiving other live events, but the signed channel reply remains invisible.

Sending any reply from the phone immediately makes the accumulated remote replies appear. This makes an agent look as though it has not answered until the user sends another message.

This was reproduced in both an existing long thread and a new, short diagnostic thread.

Steps to reproduce

1. On an iPhone, open a channel thread and leave it open.
2. From another client or an agent, publish a reply to that thread.
3. Observe that agent Activity updates, but the new channel reply does not appear in the open thread.
4. Wait at least 30 seconds. The reply still does not appear.
5. Send any reply from the iPhone in that thread.
6. Observe that the missing remote reply appears immediately alongside the local send.

Expected behavior

A remote reply should appear in the open thread as soon as it is received, without requiring a local send or reopening the view.

Version and platform

• Buzz version: v0.4.12 (fresh App Store install; App Store shows Open, not Update)
• OS: iOS, physical iPhone
• Relay: self-hosted Buzz relay

Logs / additional context

Relay-side verification was performed before the local send: the missing reply was already present in the thread query, so publication and persistence succeeded. The same controlled result occurred in a brand-new thread, ruling out thread length and an old scroll position.

Attempts that did not reliably surface the reply included leaving and reopening the thread, pulling to refresh, and force-closing/reopening the mobile app. A local send consistently revealed the backlog.

The likely failure boundary is the live-message-to-thread-query handoff:

• threadRepliesProvider performs a one-shot authoritative query.
• channelMessagesProvider is expected to receive a live threaded reply and invalidate threadRepliesProvider for its root/parent.
• The open thread does not rebuild for the remote arrival.
• A local send updates local reply state and/or its relay echo wakes the rebuild path.

A useful regression test would:

1. Mount/watch an already-hydrated thread replies provider.
2. Deliver a remote threaded reply through the channel live-event callback.
3. Assert that the watched thread refetches and renders the reply without adding any local reply.

Related but distinct:

• Mobile: live threaded replies never reach the channel window store, so thread summaries never update (regression from #1518) #3293 covers live threaded replies not updating the channel timeline and says opening the thread shows the reply. Here, the thread is already open and remains stale.
• [Bug] Mobile: replies sent in a nested thread never appear — thread query is root-scoped #2415 covers nested-thread root scoping and permanently missing nested sends, not live refresh of an ordinary open thread.
• [Bug] Mobile: in-thread replies to an agent do not trigger the agent #2965 covers the mirror direction: a mobile user's outbound in-thread reply does not trigger the agent. This report covers an inbound agent reply that is already stored but does not render in the open iOS thread.

No private relay URL, channel identifiers, pubkeys, or message contents are included in this report.

[foundationfivepro-gif]

Same build, broader blast radius: Buzz Mobile v0.4.12 on iOS 26.5.2, physical iPhone.

The stale-until-you-send behaviour described here is not limited to an open thread for us. Every channel and every DM stops updating at the same time, regardless of who is being mentioned, while Desktop shows the current state throughout. Force-quit and reopen is the reliable recovery; sending a message into the stale view also flushes what had accumulated, exactly as described in step 6 here.

Also worth recording: this survived a full clean slate — community removed, app deleted, reinstalled from the App Store, community re-added. The stall returned on the fresh install, so it is not leftover local state.

Given the scope, I suspect this issue is a thread-shaped view of the missing socket stall detection in #3224 rather than an independent live-message-to-thread-query bug — though the threadRepliesProvider cache analysis in that thread suggests threads additionally need their own recovery path even once the socket is fixed. I've posted the iOS details and a related finding about the resume path there.