…oopandlearn#4) Problem ------- Every time iOS killed and relaunched the app process, `activity` was nil in the new process instance. Before Fix loopandlearn#1 (activity recovery in init()), that meant each call to `update()` fell through to `start()` and called `Activity.request()`, creating a second Live Activity widget on the Lock Screen. Even after Fix loopandlearn#1 the race between process launch and the first `update()` call could still leave duplicate entries in `Activity<LiveActivityAttributes>.activities`. The user would see multiple overlapping Live Activity tiles on the Lock Screen, none of which were being updated by the current process. Fix --- Inside the Task that handles a normal (non-starting) update, iterate over all entries in `Activity<LiveActivityAttributes>.activities` and end any whose `id` does not match the activity this manager owns. Each orphan is ended with `.immediate` dismissal so it disappears from the Lock Screen right away rather than lingering in a "stale" appearance. This mirrors the cleanup pattern used in Trio's LiveActivityBridge `pushUpdate()` method: for unknownActivity in Activity<LiveActivityAttributes>.activities .filter({ self.currentActivity?.activity.id != $0.id }) { await unknownActivity.end(nil, dismissalPolicy: .immediate) } The cleanup runs inside the existing Task so it shares the same async context as the update call — no extra concurrency overhead. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Uh oh!

Loop Status Icon isn't always correct #4

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions