Agent host: fix realsdk integration tests#314915
Merged
roblourens merged 3 commits intomainfrom May 7, 2026
Merged
Conversation
Contributor
|
Base:
|
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the @github/copilot npm dependency from 1.0.39 to 1.0.43 in the main VS Code repo and the remote/ package, including corresponding package-lock.json updates so CI/builds consume the new version.
Changes:
- Bump
@github/copilotto1.0.43in rootpackage.jsonandremote/package.json. - Regenerate root and
remote/package-lock.jsonentries for@github/copilotand its platform-specific optional dependencies.
Show a summary per file
| File | Description |
|---|---|
| package.json | Updates root dependency pin for @github/copilot to 1.0.43. |
| package-lock.json | Updates resolved tarball/integrity and optional platform packages for @github/copilot@1.0.43. |
| remote/package.json | Updates remote/ dependency pin for @github/copilot to 1.0.43. |
| remote/package-lock.json | Updates resolved tarball/integrity and optional platform packages for @github/copilot@1.0.43. |
Copilot's findings
Files not reviewed (1)
- remote/package-lock.json: Language not supported
- Files reviewed: 2/4 changed files
- Comments generated: 1
After createSession became provisional, notify/sessionAdded is deferred until the agent materializes on first sendMessage. The realsdk integration tests waited for sessionAdded immediately after createSession and timed out (15s) for every test. The provisional session state is registered in the state manager and addressable by the URI the client passed in, so subscribe directly using that URI without waiting for the notification. Synthesize the SessionAddedNotification from the snapshot when needed. The worktree test reorders to wait for sessionAdded after dispatchTurn, since the .worktrees/... path only exists after materialization. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
b92fa4d to
f619de4
Compare
The teardown loop after the main assertion called `waitForNotification` with a predicate that matched ANY `session/toolCallReady`, including the one we'd already approved earlier in the test. `waitForNotification` returns synchronously when an existing notification matches the predicate, so the loop kept finding the same already-handled toolCallReady on every iteration without yielding the event loop — spinning at 100% CPU until the 90s timeout fired. Track processed serverSeqs so the predicate skips notifications we've already handled, mirroring the pattern used elsewhere in the file (driveTurnToCompletion / startBackgroundApprovalLoop). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
dmitrivMS
approved these changes
May 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The realsdk integration tests in
src/vs/platform/agentHost/test/node/protocol/had two issues that prevented the suite from running cleanly:1. Provisional sessions broke the
notify/sessionAddedwait patternAfter commit 8309b22 made
createSessionreturn provisional sessions,notify/sessionAddedis deferred until the agent materializes on firstsendMessage. The realsdk tests waited forsessionAddedimmediately aftercreateSessionand timed out (15s) for every test.Fix: subscribe directly using the URI we passed to
createSession(the provisional state is registered in the state manager and addressable by that URI). Synthesize theSessionAddedNotificationfrom the snapshot when needed. The worktree test reorders to wait forsessionAddedafterdispatchTurn, since the.worktrees/...path only exists post-materialization.2. Busy-loop in
strips redundant cdtestThe teardown loop at the end of the test called
waitForNotificationwith a predicate matching ANYsession/toolCallReady, including the one we'd already approved.waitForNotificationreturns synchronously when an existing notification matches, so the loop kept re-finding the same already-handled notification on every iteration without yielding the event loop — spinning at 100% CPU until the 90s timeout fired.Fix: track processed
serverSeqs in the predicate so the loop only matches new toolCallReady notifications, mirroring the pattern used bydriveTurnToCompletionandstartBackgroundApprovalLoop.Validation
npm run compile-check-ts-nativenpm run gulp compile-clientassertCleanStateplanning-mode session-state writes are auto-approved in default mode— model emits a tool call that triggers a confirmationterminal-driven file edit shows up in summary.diffs— git-driven diff not produced for the expected URIwrite_bash never triggers a permission requestnot yet observed end-to-endNo production code changes — test scaffolding only.