Keep the expected managed settings 404 out of the DevTools console

[joshspicer]

Problem

Developer Tools logs this repeatedly, and it looks like a failure:

api.github.com/copilot_internal/managed_settings:1  Failed to load resource: the server responded with a status of 404 ()

The 404 is not a problem — it is how the endpoint says "this account has no managed settings", and DefaultAccountProvider already handles it as a normal outcome. The problem is purely that it gets printed.

Why it can't be fixed in the renderer

Chromium emits that line from the document's network stack for any response with an error status. Measured via the DevTools Log domain (Log.entryAdded, which is exactly what the console renders):

request from the renderer	printed?
fetch	yes
XMLHttpRequest	yes
fetch + keepalive / cache: 'no-store'	yes
same, inside an iframe	yes

There is no request option that suppresses it, and it is not a console.* call that could be filtered.

Fix

Rewrite the status in the main process before the response reaches the window, using the same session.defaultSession.webRequest.onHeadersReceived mechanism that already sits a few lines above in app.ts (used to add Access-Control-Allow-Origin for the PRSS CDN). The real status travels in a response header that the workbench restores immediately, so every downstream code path still sees the 404 it sees today — including the retry-next-session logic and the noSettings handling.

Scope is deliberately tight: only a 404, only from https://api.*/copilot_internal/managed_settings (covering GHES, whose host is also api.-prefixed). Any other status, endpoint or genuine failure is reported exactly as before.

One subtlety worth flagging for review: the request is cross-origin, so the marker header is invisible to the window unless it is added to Access-Control-Expose-Headers. That list is extended, not replaced — replacing it would hide the x-ratelimit-remaining / retry-after headers that the rate-limit logic reads off this same response.

Verification

Ran the shipped predicate and handler verbatim in Electron (the .build/electron binary this repo uses), against a real https://api.github.com/copilot_internal/managed_settings?client_id=… URL served by a local HTTPS endpoint that mimics GitHub's response (CORS, its own access-control-expose-headers, x-ratelimit-remaining), with the DevTools Log domain attached:

managed_settings (real URL + query)
   renderer: {"status":200,"original":"404","rateLimit":"4999","body":"{\"message\":\"Not Found\"}"}
   console : silent
other copilot endpoint (untouched)
   renderer: {"status":404,"original":null,"rateLimit":"4999","body":"{\"message\":\"Not Found\"}"}
   console : PRINTS -> Failed to load resource: the server responded with a status of 404 (Not Found)

So: the noise is gone, the true status is recovered, the rate-limit headers survive, and neighbouring endpoints are unaffected.

Also: scripts/test.sh on the three related suites (53 passing, including new unit tests for the URL predicate and the status restore), plus tsc -p src/tsconfig.json, eslint, and valid-layers-check.

Notes

• Desktop only. The web workbench still prints it; that would need the service to stop answering 404.
• While investigating I found a separate, unrelated inefficiency: findMatchingProviderSession lists one session once per scope set it matches, so a full-scope GitHub session is listed 3× and the identical request is sent 3× with the same token. That is a real bug but it is not the cause of the printing, so I have left it out of this PR — happy to send it separately.

[vs-code-engineering]

📬 CODENOTIFY

The following users are being notified based on files changed in this PR:

Robo (@deepak1556)

Matched files:

• src/vs/code/electron-main/app.ts

[Copilot]

Pull request overview

Adds desktop request routing to prevent expected Copilot API failures from cluttering renderer DevTools.

Changes:

• Adds an expected non-success request hint.
• Routes flagged desktop requests through the main process.
• Applies the hint to Copilot account requests.

Show a summary per file

File	Description
src/vs/base/parts/request/common/request.ts	Adds the request hint.
src/vs/code/electron-main/app.ts	Registers the main-process request channel.
src/vs/workbench/services/request/electron-browser/requestService.ts	Routes flagged requests through IPC.
src/vs/workbench/services/accounts/browser/defaultAccount.ts	Flags Copilot account requests.

Review details

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Suppressed comments (1)

src/vs/workbench/services/request/electron-browser/requestService.ts:51

• This main-process path no longer honors cancellation or timeout while the response body is being read. RequestChannel buffers the body only after the main IRequestService.request resolves, but the Node request implementation clears its timeout and cancellation listener as soon as response headers arrive; unlike the renderer fetch(...).arrayBuffer() path, a stalled body can therefore hang startup/account resolution indefinitely. Keep the token and timeout active through IPC body buffering before routing these requests here.

		if (options.expectNonSuccessStatus) {
			return this.logAndRequest(options, () => this.mainProcessRequestClient.request(options, token));

• Files reviewed: 4/4 changed files
• Comments generated: 4
• Review effort level: Balanced