Repository navigation
Copilot thread cannot resume after interruption #42
Description
The sequence below was observed once and has not been independently reproduced.
Summary
A T3 Code thread using the GitHub Copilot provider stopped accepting new turns
after a run was interrupted. The first failures cited background work; a later
attempt failed because native Copilot session replacement was unsupported.
The Copilot CLI session remained accessible, and a new T3 thread worked.
Environment
- T3 server:
0.1.4-preview.20261103.1 - Host: Linux, x86-64
- Provider: GitHub Copilot
- The current
copilot --versionreports1.0.106-9. The CLI version used by
the failed run has not been established.
Observed sequence
-
A Copilot-backed T3 thread had an active run and background work. The user
queued and steered messages but did not see responses. -
The user interrupted the run and sent another message. At 22:03:35 UTC on
November 5, 2026, the provider turn failed before starting:The target provider still has background work running. Wait for it to
finish or stop it before retrying the handoff. -
The user reports stopping the server and background task. A later turn
failed with the same message at 22:06:15 UTC. -
A subsequent turn failed before starting at 22:08:06 UTC:
Native Copilot session replacement is unsupported.
-
The previous conversation was still reachable in Copilot CLI. Creating a
new T3 thread allowed work to continue.
Expected
After the relevant background work has stopped, the existing provider session
should resume, or T3 should identify the remaining work and provide a safe,
actionable recovery path that preserves the conversation.
Actual and unknown
The original T3 thread ended in a failed state with no active T3 run. New turns
did not start. Whether a provider-side background process was still running,
why replacement was attempted, and whether a server process actually crashed
are not established. The exact reproduction rate has not been confirmed.
Session and thread IDs, plus screenshots of both errors, are available privately on request.
Activity
jdbencardinop commentedon Nov 6, 2026
Investigated against the newly source-qualified
mainat0490e7bb2753ee455d58f9832f6ea943af81b0e0(fork-v0.1.4-1), not the older preview package reported here.The recovery paths now include the #39 fixes: native Copilot explicitly disables native-thread replacement; resume failures preserve their original error and native identity instead of attempting unsupported replacement; cumulative billing is no longer treated as context occupancy. The #35 idle-agent fix is also present. These address mechanisms consistent with the reported errors, but do not establish the cause of this particular incident.
Focused current-source controls passed:
vp test run packages/provider-copilot/src/server/adapter.test.ts apps/server/src/orchestration-v2/testkit/ProviderSwitch.integration.test.ts -t 'resumes the same native identity|starts a replacement native thread|retains background task state|completes exactly once on root|keeps the native session after turns refused'— 9 passed.vp test run apps/server/src/orchestration-v2/testkit/ProviderSwitch.integration.test.ts -t 'preserves handoffs through (prior-images-cumulative-native|screenshot-exhausted-target-no-replacement-native|screenshot-exhausted-target-background-native)'— 3 passed.These are deterministic adapter/persisted-orchestration fixtures, not a reproduction of the affected Linux conversation. No live session was changed and no paid turn was sent. Keeping this issue open pending receiving-host evidence: exact packaged source/SDK/CLI identity, whether native background work remained, and a fixture-only interruption/retry trace on the updated source. The existing private evidence prompt can be used; do not post raw session IDs, private screenshots, credentials or conversation logs here. Main/source acceptance does not qualify a new Linux package or imply that the reported preview was updated.
jdbencardinop commentedon Nov 6, 2026
New reproduction lead from a second observation: the visible stall begins after a steering message, rather than only after an explicit stop/restart.
Reported sequence:
The private screenshot confirms the superseded-attempt label, steer label, pending-style follow-up bubble and active stop control. The cropped screenshot does not itself show the thread-list indicator or establish native delivery/completion; those are user reports.
The affected chat has not been restarted, so recurrence of the original resume/import error is untested. Exact build/runtime provenance and the affected native identity are not established for this second observation. This is a steering/event-ownership or delivery-fencing investigation lead—not proof of a race, a network outage, or a confirmed common root cause with the first incident. Automatic reconnection or prompt resend must not be used to mask it without proving safe ownership and deduplication.
Original screenshot and message text remain private. No live thread was restarted, cancelled, resumed or modified during recording.
jdbencardinop commentedon Nov 6, 2026
Isolated stall mechanism and source-qualified candidate
I reproduced one concrete mechanism on validated main
0490e7bb2753ee455d58f9832f6ea943af81b0e0: a rejected routing-state read during native abort kills Copilot's internal event consumer, but leaves its public event queue open. The subsequent native idle and drain receipts then have no consumer. This uses a disposable fake native session, not the reported live conversation.The candidate makes that failure visible as
ProviderAdapterEventStreamError, preserves the underlying protocol/original cause, closes the unusable ingress queue, and makes pending/later drains observe the worker failure. It adds no native retry, prompt resend, reconnect, or replacement conversation.Published branch:
tpatch/copilot-steering-event-delivery. Product landing:0c550b8487. Qualification and asserted runtime transcript.The new regression hangs before the correction at the existing project test ceiling; afterward all 38 adapter cases pass.
vp run check:changedpasses, including 10 affected package typechecks. The actual landing's canonical patch and committed recipe reproduce it exactly; all 31 maintained canonical roots reconstruct the candidate's product tree and modes from pinned upstream without unexplained differences.Native tpatch verification still fails at the existing historical
copilot-cli-providerparent-landing drift. It recognizes the new landing as exact and its current canonical postimage as materialized-clean. The failed report is retained, not relabeled a pass.Limits: this adapter-level reproduction does not establish the reported incident's cause or prove complete orchestration fallback-steer/queued-message recovery. The receiving-host evidence is still needed. #42 remains open. Main, installed apps, and the reported live chat are unchanged; no PR or deployment was made.
jdbencardinop commentedon Nov 10, 2026
Additional macOS installed-preview observation (2026-11-10)
Confirmed against installed macOS Fork Preview
0.1.4-preview.20261103.1. This is an older packaged runtime, not verification of the newer source-qualified candidate.Read-only inspection before recovery established:
assistant.turn_endandassistant.idleevents.running, with no completion timestamp. The client showed approximately 94 hours Working. The user reports closing the Mac lid around the time of the stall; sleep as the cause is not established.ProviderTurnControlError: the previous provider turn did not terminalize before restart. Native abort/idle events were logged during those attempts.User-approved recovery through supported T3 controls:
The target provider still has background work running. Wait for it to finish or stop it before retrying the handoff.Conversation history, the native Copilot session files, and uncommitted candidate changes remain present. The native session still has a live runtime ownership lock; CLI takeover has not been attempted or qualified.
This adds installed-host evidence for stale completion plus failed restart recovery. It does not prove a shared root cause with earlier reports, that background-work refusal is itself incorrect, or that newer source fixes resolve this incident. A safe next investigation should distinguish root idle/completion ingestion from background-command ownership and the subsequent handoff admission decision. No private session/thread IDs, machine paths, raw transcripts, credentials, or screenshots are included here.
Model/harness: GPT-6.1 Sol (
gpt-6.1-sol), GitHub Copilot through T3 Code.jdbencardinop commentedon Nov 11, 2026
Additional macOS observation: explicit Stop followed by immediate continuation failure (2026-11-11)
The maintainer attempted explicit Stop as a precaution around an overnight pause, then sent a normal continuation. That did not recover this thread.
Affected installed application: macOS Fork Preview
0.1.4-preview.20261103.1, confirmed from its application metadata. This is the older packaged runtime, not a qualification of current main or the newer source candidates.Read-only inspection of the durable journal establishes:
class: provider_error,message: Provider turn failed., with no code or retryability detail. The provider-thread projection returned to idle.This differs from the earlier admission refusal quoting outstanding background work: this attempt passed into ready/running before failing, approximately 360 ms after start. The UI screenshot agrees with the generic provider-error result. It does not establish a process crash, successful native prompt consumption, or a specific underlying provider exception.
Native diagnostics continue to contain shell-output/partial-result notifications after Stop and around the failed retry. Those notifications alone do not prove an active model turn or identify the failure's cause. Sleep as a cause, a common root cause with earlier incidents, and whether newer source fixes resolve this path remain unproven.
The same conversation also previously encountered a separate worktree-handoff failure: the workspace move completed, intentional provider detachment was classified as an unexpected stream failure, and the same-provider failure guard held its durable continuation for roughly five hours. That evidence is already recorded in #33 (#33 (comment)); it should be distinguished from this later Stop/retry failure rather than treated as the same proven defect.
Current recovery approach: continue the work in a fresh conversation using the preserved worktree and recorded decisions. The old thread has no active application run, and its uncommitted candidate remains present. Inspection did not restart or attach another controller to its native session, stop background processes, or write to the live database.
Next investigation should preserve the original provider failure through adapter/orchestration reporting, distinguish outstanding command ownership from active-turn state after Stop, and reproduce explicit Stop -> same-native-thread continuation in a disposable persisted fixture. No automatic resend, replacement native conversation, or broad queue-unholding workaround is qualified.
Private session/thread identifiers, transcripts, device identifiers, credentials, paths and screenshots are intentionally omitted.
Model/harness: GPT-6 Astra (
gpt-6-astra), GitHub Copilot through T3 Code.jdbencardinop commentedon Nov 12, 2026
The maintainer authorized a new eight-hour implementation window on November 12, 2026, from 20:39:14 UTC to November 13 at 04:39:14 UTC (12:39 PM–8:39 PM Pacific). The final 45 minutes are reserved for checkpointing and handback.
Priority: finish the preserved read-only import candidate and its three review findings (import-time containment, selected-model provenance, malformed-journal validation), then a separately scoped recovery candidate for #42. Naming/explicit-Steer qualification is conditional on completing higher-priority gates.
Approved: scoped feature commits/pushes after checking CI side effects, sanitized existing-issue updates, isolated web/iOS Simulator evidence, at most four disposable native test turns, one independent reviewer and one follow-up. No PR, main merge, release/deployment, physical-device update, live database modification, force-push, or native-session takeover. No active-session worktree handoff.
The original external-owner SDK limitation remains a hard boundary: history import stays explicitly read-only; unsafe native continuation is not an acceptable shortcut. Existing dirty candidates and historical replay records will be preserved. Incomplete checks and the known native verifier limitation will not be reported as passes.