Repository navigation
Mobile: open threads never refetch after a reconnect — replies missing until app restart #4830
Description
On mobile, a thread's replies are fetched once when the thread is opened and never again — the query watches only the session notifier, which never changes identity, so it never re-runs for the lifetime of the app.
What that looks like: your phone sits backgrounded, a reply arrives, you come back and open the thread — the reply isn't there, and no amount of waiting brings it in. Only a full restart shows it. On a device capture, a reply posted 14 seconds into a 350-second background window never appeared in the open thread.
The reply is unreachable through the other paths too: the replayed live subscription starts at reconnect time, and the channel-window backfill carries thread summaries rather than reply bodies.
Related: #3293 (live replies never reach the window store) and #2971 (Android DM replies not visible) — different mechanisms, same result of replies silently missing.
We have a fix running in a sideloaded build since 2026-08-04: refetch thread replies once on the disconnected-to-connected edge (the idiom the read-state provider already uses), plus autoDispose on the thread-reply providers so a reopened thread queries fresh instead of serving a stale one-shot result. Happy to open the PR — it's about 30 production lines plus regression tests.
Activity
NorthPineCreations commentedon Aug 5, 2026
Confirming we hit this daily. Self-hosted community (relay 0.2.0), iOS app 0.4.12 from the App Store, small e-commerce team where non-technical users interact with several ACP agents from their iPhones.
The symptom is exactly as described: an agent reply that lands while the phone is backgrounded never appears in the open thread, no matter how long you wait after coming back. Only a full force-quit and relaunch shows it. For non-technical teammates this reads as "the agent ignored me", which undermines trust in the agents far more than the actual delay does. Combined with #4657 (no push registration), mobile is effectively a read-only surface for agent workflows right now.
A review of #4831 would be much appreciated. The refetch-on-reconnect approach reusing the read-state provider's idiom reads as low-risk from the outside, and it comes with regression tests. Happy to help verify on a real self-hosted deployment once there's a build to test.
fix(mobile): recover stale and shuffled messages (block#6691)
fix(mobile): recover stale and shuffled messages (block#6691)