fix(swift-ios): reopened threads no longer show stale history after swipe back - #11491
Conversation
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — This is a small, self-contained SwiftUI bug fix that changes only compact-width swipe-back state handling, preserving the thread detail view instead of destroying and recreating it. The surrounding code confirms the lifecycle impact is localized to avoiding stale cached thread content. You can add or adjust custom eligibility rules. Learn more. |
|
Release Smoke failure is inherited from the base branch, not this change. The job fails in
|
|
Pushed 57617af, a cherry-pick of main's #11426 (pin |
Dismissing prior approval to re-evaluate 57617af
…wipe back Leaving a thread with the swipe-back gesture cleared the selection, which destroyed the thread view while the split view was still finishing its interactive pop. The next open of that thread received onAppear followed by a spurious onDisappear, and releaseThread cancelled the load before it could subscribe or arm the HTTP fallback. The view then showed the cached transcript with no sync indicator until the user backed out and reopened. Collapse the compact column on swipe back and keep the selection, which is what the system back button already does. The view is re-shown instead of recreated, its task re-runs, and the cached resume replays new events. Model: Claude Fable 5.1. Harness: Claude Code inside T3 Code.
57617af to
6a6e572
Compare
Dismissing prior approval to re-evaluate 6a6e572
What Changed
On compact width, the swipe-back gesture now only collapses the split view column. It no longer clears the thread selection. This is the same thing the system back button does, so the thread view is re-shown rather than destroyed and recreated. One line in
WorkspaceView.swiftplus a comment explaining why.Why
Reopening a thread after leaving it with swipe back showed the cached transcript and never caught up. No pill, no updates, until the user backed out and reopened. It was most visible after a background trip because new content had arrived in the meantime.
Instrumenting the simulator build showed the sequence:
selectedThreadID, destroying the thread view while the split view was still finishing its interactive pop.onAppearfollowed by a spuriousonDisappearwhile still on screen.releaseThread, which cancelled the load before it subscribed to the socket or armed the HTTP fallback.Leaving with the nav-bar back button keeps the selection and re-shows the same view, and every reopen on that path was fresh. Making the swipe path do the same removes the trigger.
Lifecycle log, before (the reopen is instance 3D1EF3):
After, same flow:
Verification
synchronized. Also verified the swipe, background, foreground, reopen variant.Checklist
Model: Claude Fable 5.1. Harness: Claude Code inside T3 Code.