[Bug]: iOS Live Activity keeps showing "T3 Done" for hours when no other agent event arrives #11939

Activity

1. juliusmarminge commented on Sep 15, 2026

   

   juliusmarminge

   on Sep 15, 2026

   Member

   More actions

   Triage

   Confirmed on main @ 3efdcc529. This is a real relay bug, not a mobile-widget defect, and it is not a duplicate of #11938, #10864, or #11886.

   User docs already promise the 15-minute window: “Finished results remain visible for up to 15 minutes” (docs/user/mobile-notifications.md). The Done card is drawn; the end push that should retire it never fires unless something else happens.

   What the code does today

   makeAggregateState in infra/relay/src/agentActivity/agentActivityAggregate.ts keeps a completed/failed row in the aggregate for TERMINAL_AGENT_ACTIVITY_DISPLAY_TTL_MS (15 minutes), then returns null. chooseLiveActivityDelivery in ApnsDeliveries.ts turns that null into live_activity_end (after the 2-minute freshly-armed grace).

   That recompute only runs on two event paths:

   1. An environment publishes a new awareness state (AgentActivityPublisher.publish).
   2. The app re-registers its activity token (replayForLiveActivityRegistration from registerLiveActivity / foreground reconciliation).

   A phone that finished a turn and then sits idle hits neither path. The 5-minute cron in infra/relay/src/worker.ts only pruneTerminals DB rows older than 30 minutes. It does not recompute aggregates or enqueue APNs. So the lock-screen / Dynamic Island card stays on the last live_activity_update (“T3 Done”) until another agent event arrives, the user foregrounds the app after the 15-minute TTL, or iOS eventually retires the activity (hours later).

   Tapping the island or the notification does not locally end the card. Client activity.end("immediate") is only used on sign-out and duplicate-instance cleanup (remoteRegistration.ts). Opening the app inside the 15-minute window just replays the same Done aggregate. Opening it after the window is the documented workaround, because replay then sees null and sends the end.

   The completion itself is an update, not an end. ApnsClient puts stale-date = delivery + 10 minutes on updates and only puts dismissal-date on end events (5 minutes with content, 15 seconds without). iOS can dim the card; it cannot dismiss it without that later end. Ending immediately on completion would also clear activityPushToken in LiveActivities.markDelivery, so a follow-up turn within the 15-minute window could not update the same card. The update-then-end design is intentional; the scheduled end is what is missing.

   Android already honors the same 15-minute policy without a second push: fcmPayloads.ts sends activity_expires_at = updatedAt + 15m, and the native adapter calls setTimeoutAfter. That is why this is iOS-only.

   Related, not a duplicate

   Issue / PR	Why it does not close this
   #11938 / open #9081	Fresh “Done” alerts when thread.updatedAt moves (model change / settlement). Pins terminal awareness time. Does not send live_activity_end after 15 minutes of silence.
   #11886 / open #11914	Startup catch-up treated as new alerts. Marks reconnect as silent replay. A republished completed row would keep the Done card, not schedule its retirement.
   #10864	Accepted enhancement: unify iOS stale-date (delivery clock) vs Android activity_expires_at (state clock). Policy for which timestamp to use once a delivery happens. This bug is that iOS never gets the end delivery at all when idle. Keep #10864 open; do not merge the two.
   #10863	Diagnostics follow-up from the same Android audit. Not this gap.
   #9057	First-launch-after-update auto-settle flood. Different trigger.
   Open #11073	Concurrent threads hiding iOS alerts. Selection, not expiry.

   No open or merged PR adds a delayed / cron live_activity_end after the 15-minute display TTL. Searched live_activity_end, pruneTerminal, and Live Activity expiry PRs; nothing claims this.

   Suggested fix (relay only)

   Do not fix this in the iOS widget, and do not send end on the completion update (that drops the activity token).

   1. On the existing */5 * * * * cron, after (or before) pruneTerminal, sweep armed iOS targets (activity_push_token set, ended_at null). Recompute makeAggregateState and call sendForTarget. A now-null aggregate already maps to live_activity_end and already respects the freshly-armed grace.
   2. Optionally align the prune cutoff (30 minutes) with the 15-minute display TTL after the end is queued, so cleanup cannot race delivery.
   3. Regression: armed iOS target + only a completed row older than 15 minutes + no further publish → sweep queues live_activity_end. Current tests cover “null aggregate ends the card” and “TTL drops the row from the aggregate,” but nothing asserts that the cron/time passing alone produces the end.

   A per-completion delayed APNs job is an alternative to a user sweep; either is fine if it re-reads current state before sending (so new work in the window cancels the end).

   Workaround

   Start another turn on any linked environment, or foreground the app more than 15 minutes after the turn finished so token re-registration replays an empty aggregate. Swiping the Live Activity away also works. A mobile OTA will not fix an idle phone that never opens.

   Severity: minor (card lies about being current; no lost work). Still a documented product-policy miss, and it only clears by accident.

   Accepting as a bug on infra/relay. Keep #10864 as the clock-policy follow-up. Do not attribute Closes #11939 to #9081 or #11914.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   acceptedfeature request acceptedfeature request accepted

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 15, 2026