Go Copilot SDK v1.0.9: session/client teardown is not caller-deadline-bounded after SendAndWait cancellation

[shiv-kumar-ais]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Copilot SDK

Body

We encountered a substantial deadline overrun in a concurrent review application using the Go Copilot SDK. Workers had 300-second deadlines, but some recorded execution durations reached approximately 1,732 seconds. The overall invocation took 29 minutes before returning a technical failure.

Our investigation identified SDK lifecycle behavior that prevents the application from guaranteeing bounded cleanup using its current integration. We are not claiming that these source observations conclusively explain every minute of the production overrun; we would appreciate help establishing the supported cancellation/shutdown contract.

Environment

Component	Version/details
Go Copilot SDK	github.com/github/copilot-sdk/go v1.0.9
Copilot CLI	1.0.93
OS	Windows 10.0.26200.0
Shell	PowerShell 7.6.6
Application	PWI Code Review, Copilot SDK adapter 0.15.2-rc.2
Requested review route	gpt-5.6-sol, high reasoning effort
Concurrency	Global/per-route capacity 10; observed review peak 10
Authentication	Authenticated official Copilot CLI
Host policy	Unchanged; no application-control denial observed during this invocation

One SDK client is shared across isolated worker sessions.

Observed production failure

Exactly one authorized review ran on October 7, 2026:

• Start: 2026-10-07T16:33:31.1596500-04:00
• End: 2026-10-07T17:02:40.1259785-04:00
• Elapsed: 1748.9599613 seconds
• Application exit code: 3
• Primary failure: waiting for session.idle, followed by context deadline exceeded
• Primary worker timeout: 300 seconds
• Primary recorded deadline: 2026-10-07T20:38:46.2575066Z
• Primary SDK session ID: 36fe9d92-32ef-48cd-8817-dabbd6764581

Representative error:

waiting for session.idle: context deadline exceeded

Four classifier sessions completed. The subsequent review phase recorded three completed, nine failed, and eight canceled tasks. Seven canceled tasks never started. No second attempts or throttle retries occurred.

Some workers returned after approximately 350–356 seconds; others recorded durations around 1,732 seconds despite their 300-second deadlines.

Seven completed raw worker submissions survived. The application failed closed and did not produce an authoritative review result.

SDK lifecycle findings

Relevant pinned source:

• [Go session implementation, v1.0.9](http://github.com/github/copilot-sdk/blob/v1.0.9/go/session.go)
• [Go client implementation, v1.0.9](http://github.com/github/copilot-sdk/blob/v1.0.9/go/client.go)

Our investigation found:

1. Session.SendAndWait cancellation stops waiting but does not abort agent work. The SDK documentation explicitly describes this distinction. Applications therefore need a separate cancellation/abort step.
2. Session.Disconnect uses a background context for session destruction. The application's expired worker context does not bound that cleanup operation.
3. Client.Stop disconnects sessions before reaching its runtime-shutdown timeout. Consequently, that shutdown timeout does not bound the preceding session-disconnection phase.
4. SDK callback-response paths also use background contexts. The investigation found no event-processor joining mechanism sufficient to establish that all relevant background work has terminated.
5. We have not established a supported, concurrency-safe use of ForceStop that resolves these boundaries while preserving correct lifecycle handling.

Our previous application cleanup deferred Disconnect after SendAndWait. It explicitly aborted retryable throttle failures, but not ordinary deadline/cancellation failures. We recognize that as an application-side gap and are addressing it with a fresh, bounded abort context and explicit cleanup diagnostics.

However, bounding an abort attempt does not by itself bound subsequent context-free cleanup.

Evidence limitations

We retained the full failed run, worker diagnostics, schedules, partial outputs, and SDK session metadata.

External-tool request/completion metadata pairs were present, but we do not have a raw transport RPC trace. Tool-completion metadata is not proof that every SDK reply or destruction RPC completed.

We therefore cannot yet distinguish conclusively between:

• remote work continuing after the caller stopped waiting;
• a delayed or missing idle event;
• a blocked callback-response RPC;
• blocked session destruction;
• subsequent client shutdown.

No live throttling was observed. We are not treating these deadline failures as evidence of throttling.

Suggested deterministic reproduction

Please validate this without model inference using a controlled JSON-RPC peer:

1. Create a session and acknowledge session.send.
2. Withhold session.idle until the caller’s short deadline expires.
3. Attempt abort using a fresh context with its own deadline.
4. Withhold the response to session destruction.
5. Observe whether Session.Disconnect and subsequently Client.Stop return within a caller-controlled bound.

This is a proposed isolation procedure, not a claim that a completed standalone reproducer is already attached.

Requested SDK guidance or fix

Please clarify or provide:

• a context-aware, bounded session-disconnect API;
• a bounded client-stop API covering all cleanup phases;
• the supported sequence after SendAndWait deadline/cancellation;
• documented handling of outstanding callbacks and reply RPCs;
• a safe escalation path when graceful cleanup fails;
• deterministic regressions covering an unresponsive destruction RPC and cancellation during callback processing.

If a newer SDK already addresses these boundaries, please identify the relevant release and supported migration path.

The confirmed lifecycle observations concern the Go Copilot SDK integration. We do not have evidence that every Copilot language SDK—or unrelated application distributions—has the same defect.

---

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[RizgarOzan]

I went through the Go source on main (v1.0.19) and your points 2 and 3 still hold there. Disconnect() sends session.detach with context.Background(), and Stop() disconnects each session in turn before its 10s runtime-shutdown timer even starts. So right now there's no graceful path the caller can bound.

The escape hatch the SDK documents is in the ForceStop doc comment: run Stop() in a goroutine and call ForceStop() if it doesn't come back in time. Since v1.0.18 ForceStop also retires the sessions, so a pending SendAndWait returns "session closed before response completed" right away instead of waiting out its ctx. The v1.0.18 release notes say there are no user-visible changes, but it's in the diff: github/copilot-sdk@v1.0.17...v1.0.18

The catch is that ForceStop is client-wide. With one client shared by 10 workers, a single stuck worker means killing everyone's sessions, so if you need a hard per-worker bound I think a client per worker is the only way to get it today.

Per worker it'd look roughly like this:

abortCtx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
_ = session.Abort(abortCtx)
cancel()

done := make(chan error, 1)
go func() { done <- session.Disconnect() }()
select {
case <-done:
case <-time.After(10 * time.Second):
	client.ForceStop()
}

The leaked Disconnect goroutine doesn't hang forever after that: the JSON-RPC wait in go/internal/jsonrpc2 also selects on the client's stop channel, so it returns "client stopped" once ForceStop closes the client.

For an actual fix (a ctx-aware Disconnect/Stop), I'd open an issue on github/copilot-sdk, that's where the maintainers are. The closest existing one is github/copilot-sdk#1273, same "disconnect is cooperative" problem but filed against Node.