Mobile app doesn't show threaded replies visible on Desktop #3046

Activity

1. 0xGyver commented on Jul 27, 2026

   

   0xGyver

   on Jul 27, 2026

   Author

   More actions

   I realized after adding this that closing and re-opening the app allows the threaded replies to be seen.
2. jerredhurst commented on Jul 30, 2026

   

   jerredhurst

   on Jul 30, 2026

   More actions

   Still reproducing on iOS as of 2026-07-30, and I have wire-level evidence that narrows it to the client.

   (Written by an AI agent working in my workspace, posted under my account. Details below are reproducible; no private channel data included.)

   Relay delivery is not the problem

   I opened a raw NIP-42-authenticated WebSocket subscription against the relay using the same filter shape the clients use for a channel live tail — kinds: [channel event kinds + 39005], #h: [channel], since: now, limit: 1000 — then published a threaded kind:9 reply from buzz-cli into that channel. Both the reply and the relay-signed kind:39005 thread-summary recount arrived on the subscription 4ms apart, ~immediately after publish:

   authed, subscribing
   EOSE                                       (+100ms)
   EVENT kind=9      e-tags: [[<root>, "reply"]]
   EVENT kind=39005  {"descendant_count": …}   (+4ms)
   

   So the event reaches any subscribed client. Whatever drops it is client-side.

   Code trace on main (ab55fee)

   Two things stack up in mobile/lib/features/channels/:

   1. threadRepliesProvider is a one-shot FutureProvider.family with no autoDispose — thread_replies_provider.dart:32. Once it resolves for a (channelId, rootId) pair it stays cached for the life of the app process. Navigating away from the thread and back does not refetch it.

   2. Its only invalidation is unreachable on the fallback path. The sole ref.invalidate(threadRepliesProvider(...)) lives inside _mergeWindowEventIntoStore (channel_messages_provider.dart:210), which is only called from _handleWindowLiveEvent, which is only called from the _usingChannelWindow == true branch of _handleLiveEvent (channel_messages_provider.dart:177). And _fetchNewestHistory catches any error from the channel-window query, logs channel window unavailable … falling back to WS history, and latches _usingChannelWindow = false for the remainder of the session. On that branch a live reply merges into the flat timeline and the open thread is never told.

   That combination explains the intermittency precisely: a single transient POST /query failure early in a session freezes every thread opened afterwards, and because the provider never disposes, nothing short of a process restart clears it.

   Matches the reporter behavior noted upthread — force-quitting and reopening the app makes the replies appear, because that is what re-runs the one-shot future.

   This appears to be exactly what #3243 fixes

   #3243 moves the invalidation ahead of the branch so both history paths refetch. It has been open and MERGEABLE since 2026-07-27 with REVIEW_REQUIRED. From reading it against current main, the described mechanism is still present, so the fix still applies cleanly as far as I can tell.

   Related but distinct, also open: #3293 / #3344 — live non-broadcast thread replies are dropped at the channel-window storage boundary, so the parent's reply-count summary also does not update live. Both symptoms are visible in the same session, which may be why this reads as one bug.

   Happy to test a build if that helps move #3243 along.
3. bunswoDS commented on Aug 5, 2026

   

   bunswoDS

   on Aug 5, 2026

   More actions

   I can confirm 5 Aug, iOS app downloaded today, agent response on a thread does not show up on iOS client ... top level reply does though... and restarting the iOS app allows those threads to be shown -- they appear after restart of the iOS app.
   iOS 26.6
4. horry-clawd commented on Aug 6, 2026

   

   horry-clawd

   on Aug 6, 2026

   More actions

   Reproduced independently on 2026-08-06 with two separate external agents in the same kind-9 channel.

   What we verified

   • The threaded agent replies were accepted by the relay and returned by buzz messages get.
   • Each missing reply is a valid kind-9 event with the channel h tag and an e tag whose marker is reply.
   • Buzz Desktop 0.5.5 renders those same events correctly.
   • The mobile channel view renders neither threaded reply.
   • Top-level control messages from both agents (same channel and relay, but no e reply tag) appear on mobile immediately.

   Event pairs

   • Parent 394d825e8987346ff6b94d8f7ce7bd5bea27d53f81b9aa1caec6056c35246ef8 → missing-on-mobile reply 14169e9e1bd5747d8475df7d35532806ee48f6fcbb360e18fa79db16c42e7667
   • Parent 335e179dc2c6df8d10fa2f480cee27748ff7768451ffbe583a0b7b61be63eec9 → missing-on-mobile replies 202ad75cd91a19c862d2bc46472947ebdf5ecb85621ee92a813805772a8c8344 and 83eddd86eaeeb9cc8060d191fe81e2ded4e6dcca99ddaccb8ed7bfad0b30efe2

   Visible controls

   • Top-level agent events 6c71d8467e290af13488694c613fb141cd1155e1316bbd6e221c673ec05929cb and 2a922ebf752b0cadcebecc7dfcb40e5ddd5f392174db8230fe5d315a7984507c both appeared on mobile.

   This cleanly isolates the current symptom to mobile handling of threaded replies rather than agent execution, publication, relay delivery, channel membership, or general mobile channel sync. We are temporarily posting agent responses top-level as a workaround.

   Posted by an AI agent after live relay/event verification; no private message contents included.
5. FabianHertwig commented on Aug 21, 2026

   

   FabianHertwig

   on Aug 21, 2026

   More actions

   Still happening on App Store build 0.11.0 (released 2026-08-19), reproduced 2026-08-20.

   One detail that may help narrow it down: it is not only about replies arriving while the app is closed. With the thread already open, reopening the app does not bring in a reply that was posted meanwhile. Navigating away and back into the channel shows it, and so does a full restart — both force a fresh load.