[Bug]: iOS Live Activity stays on Connecting because the relay throttles the running update

[carTloyal123]

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 (root cause is in infra/relay)

Steps to reproduce

1. Link an environment through T3 Connect with agent activity publishing enabled.
2. On iOS, enable Live Activity Updates.
3. Start a new task from the iOS app and lock the phone.
4. Watch the Live Activity while the agent works.

Expected behavior

The card moves from Connecting to Working once the provider session is running.

Actual behavior

The card stays on Connecting for 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 starting when the session boots and running a few seconds later, then stays silent while the phase holds (apps/server/src/relay/AgentAwarenessRelay.ts dedupes by state identity).

The relay throttles Live Activity updates to one per 15 seconds when activeCount is unchanged and no row needs attention (shouldUpdateLiveActivity in infra/relay/src/agentActivity/ApnsDeliveries.ts). The running update lands inside that window and is dropped. Nothing retries it, so the card keeps the starting content.

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 existing activeCount, attention, and terminal-row exemptions. Timestamp and ordering churn stays throttled. A relay test that delivers a starting aggregate and then a running aggregate four seconds later fails on main and 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).

[juliusmarminge]

Triage

Confirmed. This is a real iOS Live Activity bug in the relay throttle, not a duplicate of #4950.

What happens

1. The environment publishes starting when the provider session boots, then running a few seconds later (apps/server/src/relay/AgentAwarenessRelay.ts + packages/shared/src/agentAwareness.ts).
2. The relay maps those phases to lock-screen copy in statusForPhase: starting → Connecting, running → Working (infra/relay/src/agentActivity/agentActivityAggregate.ts).
3. shouldUpdateLiveActivity in infra/relay/src/agentActivity/ApnsDeliveries.ts allows at most one Live Activity push per 15s unless activeCount changed, a row needs attention, or a row just went terminal.
4. starting → running keeps activeCount at 1 and is not attention/terminal, so the running update is returned as "suppressed". markDelivery never runs, and the server will not republish the same identity, so nothing retries.
5. The card therefore keeps the starting payload 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 running update 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 starting aggregate and then a running aggregate ~4s later. That case is missing today (ApnsDeliveries.test.ts only 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.

[carTloyal123]

There are two open PRs for this: #12798 and #12699. Which one would maintainers prefer to move forward? Happy to help get it merged.