[Bug]: SwiftUI app stops showing the running turn after a checkpoint-capture error; iOS app keeps updating #13996

Activity

1. juliusmarminge commented on Sep 27, 2026

   

   juliusmarminge

   on Sep 27, 2026

   Member

   More actions

   Triage

   This is a SwiftUI client bug. The Windows checkpoint timeout is real, but it is not what leaves the thread stuck.

   The host is doing what the server already specifies. CheckpointReactor catches a failed GitVcsDriver.checkpoints.captureCheckpoint and appends a checkpoint.capture.failed activity (summary: "Checkpoint capture failed", detail = the VCS timeout). That does not fail the turn. The React Native app is following that: same thread, same host, reply finishes ("Worked for 1m 25s"). The timeout text matches VcsProcessTimeoutError (VCS process timed out in GitVcsDriver.checkpoints.captureCheckpoint: git (<cwd>) after 30000ms). The slow taskkill / WMI cleanup is why this machine hits the 30s limit; it is not a second bug in this report.

   The client that stops is the SwiftUI TestFlight app (0.1.0, build 52), which is apps/swift-ios on t3code/rebuild-mobile-app-swift (157476f1fb), not apps/mobile. On that branch:

   • Every error-tone activity, including checkpoint.capture.failed, becomes a transcript row (NativeActivityNotice). Rows are ordered by createdAt, and parseDate uses Date.distantPast when a timestamp does not parse, which places the notice above the user bubble.
   • A local send that is still only an optimistic row is appended after the server transcript (addingPendingMessages). If the detail the client has contains the failure notice but not the authoritative user message, the notice sits above the bubble that was just sent, and no assistant reply is in that list. That matches the screenshot-less report.
   • sendMessageResolved does not release the send until a follow-up refreshThread returns. ThreadDetailView.send keeps isSending true for that whole wait, so the composer stays on the busy control while that snapshot read is outstanding. A read blocked behind the same 30s git timeout stays busy for the rest of the turn. The stop control also stays up while session.status is still running (resolveThreadState).
   • reduceActivity does not keep the activity on the thread; the render cache owns it. A decode miss returns .refresh, which clears activeRawThread and drops pending transcript publishes. Until a later snapshot is applied, further detail events are not reduced. The React Native client uses packages/client-runtime threadReducer, which appends the activity and keeps applying later events, so the same turn completes there.

   Not a duplicate. Related unmerged SwiftUI work, none of which mentions this checkpoint trigger: #10758 (release Send before the optional refresh), #10759 (transcript missing the completed reply), #10763 (selected-thread stream goes silent). Those are the right place to fix the client. The host timeout does not need to be fixed for this issue.
2. juliusmarminge

   added

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

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 27, 2026