[Bug]: iOS Live Activity shows agent needs input, but opening the thread shows "Thread unavailable"

[hiimchinh]

Summary

The iPhone lock screen Live Activity shows 1 active agent · 1 needs attention, with a thread title and an Input status. Opening the corresponding thread shows Thread unavailable, preventing a response to the agent's input request from mobile.

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/mobile (iOS)

Steps to reproduce

1. Have an agent waiting for user input.
2. Observe the lock screen Live Activity showing the thread with an Input status and 1 needs attention.
3. Open the corresponding thread from the Live Activity.
4. The Thread screen displays the error below instead of the conversation and pending input request.

The report is based on two screenshots of the observed state; reproduction frequency and the exact triggering conditions have not been established.

Expected behavior

The associated thread opens and allows the user to respond to the pending input request. If the mobile state needs to sync first, the app should load the thread or provide an actionable recovery option.

Actual behavior

The Thread screen displays:

Thread unavailable
This thread is not available in the current mobile snapshot.

No conversation or input controls are displayed, despite the Live Activity indicating that the agent needs attention.

Impact

Blocks responding to the affected agent's input request through this mobile flow. Whether opening the thread through the normal thread list works is not yet known.

Version or commit

Not recorded.

Environment

• Device: iPhone
• iOS version: Not recorded
• T3 Code mobile/server versions: Not recorded

Screenshots, recordings, or supporting files

The two supplied screenshots show the following (image files are not attached to this issue):

• IMG_5570.png: Lock screen Live Activity showing 1 active agent · 1 needs attention, the thread title, and Input.
• IMG_5571.png: Thread screen showing the exact error quoted above, with a back button and no conversation content.

Relevant code

ThreadRouteScreen.tsx contains the exact error text in ThreadUnavailableScreen. ThreadRouteScreen falls back to it when the selected thread does not match the route and the connection is not considered to be hydrating. This identifies the rendering path, not a confirmed root cause.

Workaround

None confirmed.

[juliusmarminge]

Triage

Accepted as a mobile iOS bug. Live Activity and the Thread screen use different sources of truth, and the Thread route fail-closes before the local snapshot/detail can catch up.

What we can confirm from the report + code

The lock-screen copy (1 active agent · 1 needs attention, Input) is the Live Activity widget advertising a waiting_for_input row. The banner deep-links to t3code://threads/{environmentId}/{threadId}.

The exact empty state is ThreadUnavailableScreen in apps/mobile/src/features/threads/ThreadRouteScreen.tsx. That screen is shown when:

1. The route has an environment + thread id.
2. selectedThread is missing or does not match the route.
3. The connection is not treated as hydrating.

“Hydrating” today is only isLoadingConnections or the environment being connecting / reconnecting. The route does not wait for hasPendingShellSnapshot / hasLoadedShellSnapshot (Home and New Task do), and it does not wait for the per-thread detail subscription (empty / synchronizing). If the environment runtime is not in the catalog yet, connection defaults to "available" and unavailable is immediate.

Live Activity is published by the server over relay/APNs. The Thread screen reads the phone’s connected-environment shell snapshot. Those can disagree even when the agent really is waiting for input.

Likely causes (ranked)

1. Lock-screen / cold-start race. Catalog already ready, environment not yet connecting (or already “connected” with a stale cache). Snapshot or thread detail still in flight → fail-closed instead of “Opening thread…”.
2. Environment not connected on this device. Live Activity can still update over APNs. The route treats that as settled and shows unavailable, with no reconnect action.
3. Thread not in the active mobile snapshot. The main shell query excludes archived threads (archived_at IS NULL). A waiting thread that is archived, or not yet streamed into the cached snapshot, can still appear on Live Activity.

Whether the same thread opens from the home list is still unknown and would distinguish (1) from (2)/(3).

Related, not duplicates

• [Bug]: "Loading messages..." forever on iOS app #9414 — thread opens, then “Loading messages…” forever. Later stage of hydration, different UI.
• [Bug]: Mobile thread stuck on "Loading messages..." forever when the snapshot fails schema decoding #10206 (closed) — schema-decode / stuck synchronizing. Different copy and gate.
• [Bug]: iOS 1.0.3 cannot exchange relay DPoP access token (invalid_dpop) — T3 Connect, notifications, and Live Activities all fail #7170 — opposite problem: Live Activity never registers (invalid_dpop).

No open or merged PR fixes this Live Activity → ThreadUnavailable path.

Suggested fix

Keep Opening thread… on this deep-link (and the same /threads/:env/:thread entry points: notification tap, home-screen shortcuts) until the target environment’s shell has synced or useEnvironmentThread leaves empty/synchronizing. Only then show an actionable empty state (reconnect this environment / thread not on this device / open from archive). Do not fail-closed while a snapshot is still pending.

Helpful follow-up (does not block)

• Does the same thread open from the home thread list?
• App version / TestFlight build, and whether the environment was Connected vs reconnecting when you tapped the Live Activity.
• Cold start (app killed) vs app already in foreground.

Labels: bug accepted via-triage