Repository navigation
[Bug]: iOS Live Activity stays on Connecting because the relay throttles the running update #12668
Description
Activity
Triage
Confirmed. This is a real iOS Live Activity bug in the relay throttle, not a duplicate of #4950.
What happens
- The environment publishes
startingwhen the provider session boots, thenrunninga few seconds later (apps/server/src/relay/AgentAwarenessRelay.ts+packages/shared/src/agentAwareness.ts). - The relay maps those phases to lock-screen copy in
statusForPhase:starting→ Connecting,running→ Working (infra/relay/src/agentActivity/agentActivityAggregate.ts). shouldUpdateLiveActivityininfra/relay/src/agentActivity/ApnsDeliveries.tsallows at most one Live Activity push per 15s unlessactiveCountchanged, a row needs attention, or a row just went terminal.starting→runningkeepsactiveCountat 1 and is not attention/terminal, so therunningupdate is returned as "suppressed".markDeliverynever runs, and the server will not republish the same identity, so nothing retries.- The card therefore keeps the
startingpayload until the next exempt phase (approval / input / done / failed) or until the app foregrounds and re-registers the activity token (replay after the 15s window).
#4950 is the other Connecting-stuck case: publishing disabled, so no authoritative update exists. Here publishing is on and the
runningupdate is dropped.Not the same as
- [Bug]: iOS Live Activity stays at Connecting when environment activity publishing is disabled #4950 / fix(mobile): stale Connecting live activity is retired on a bound #4980 — unpublished placeholder, client-side 60s reconcile
- [Bug]: iOS Live Activity keeps showing "T3 Done" for hours when no other agent event arrives #11939 / fix(relay): end idle Live Activities after the display window #11943 — idle Done cards lingering
- feat(mobile): degrade the agent Live Activity once its content goes stale #12047 — stale-date degrade
- fix(mobile): dismiss ended Live Activities on foreground #12656 — dismiss ended cards on foreground
- perf(relay): skip aggregate serialization on cheaply-decided updates #12029 — perf reorder of the same function; behavior-identical today, so a fix PR should land after it or absorb the reorder
Suggested fix
Exempt phase changes from the 15s throttle, next to the existing
activeCount/ attention / newly-terminal exits. Leave timestamp and ordering churn throttled.Add a relay test that delivers a
startingaggregate and then arunningaggregate ~4s later. That case is missing today (ApnsDeliveries.test.tsonly covers timestamp-only churn and attention/completion exemptions).Android FCM is unaffected; it does not use this Live Activity throttle.
Next step
Small relay PR in
shouldUpdateLiveActivity+ the starting→running regression. No mobile or contract change required.- The environment publishes
- added 2 commits that reference this issue
on Oct 6, 2026
Before submitting
Area
apps/mobile (root cause is in
infra/relay)Steps to reproduce
Expected behavior
The card moves from
ConnectingtoWorkingonce the provider session is running.Actual behavior
The card stays on
Connectingfor the whole turn. It only changes at the next phase transition (approval, input, done, failed) or when the app is foregrounded and re-registers its activity token.Cause
The server publishes
startingwhen the session boots andrunninga few seconds later, then stays silent while the phase holds (apps/server/src/relay/AgentAwarenessRelay.tsdedupes by state identity).The relay throttles Live Activity updates to one per 15 seconds when
activeCountis unchanged and no row needs attention (shouldUpdateLiveActivityininfra/relay/src/agentActivity/ApnsDeliveries.ts). Therunningupdate lands inside that window and is dropped. Nothing retries it, so the card keeps thestartingcontent.Not the same as #4950, where no update arrives because publishing is disabled.
Proposed fix
Exempt phase changes from the throttle in
shouldUpdateLiveActivity, alongside the existingactiveCount, attention, and terminal-row exemptions. Timestamp and ordering churn stays throttled. A relay test that delivers astartingaggregate and then arunningaggregate four seconds later fails onmainand passes with that change.Impact
Major degradation or frequent failure
Version or commit
main @ d6f2913, iOS 1.2.1
Notes
Investigation was LLM assisted (Claude Fable 5.1 in T3 Code).