accounts: avoid more redundant managed settings requests

[joshspicer]

Summary

• keep forceRefresh as a simple boolean that bypasses every default-account cache
• keep ordinary account refreshes cache-aware with no force flag
• preserve fresh quota/upgrade checks with an explicit entitlement-only refresh
• deduplicate authentication sessions that match multiple accepted scope alternatives
• treat a managed-settings 404 as the final cacheable no-policy result instead of retrying other sessions
• retain bounded 401 authentication fallback and fail-closed forced-freshness behavior

Why

A workbench reload could turn one managed-settings lookup into four sequential GETs. A chat entitlement update was forcing all account data to refresh, one GitHub session was selected once per matching scope alternative, and the shared request helper retried 404 responses as though they indicated a bad token.

The refresh contract remains simple: normal operation honors fresh caches; forceRefresh: true refreshes everything and is reserved for explicit policy sync/retry actions. Quota dashboards, quota reset checks, and upgrade flows explicitly refresh only entitlement data so they do not remain stale for up to one hour or invalidate unrelated caches.

Launch validation

Using an isolated authenticated Code OSS Dev profile:

• initial uncached account resolution made one request for each required account resource
• explicit entitlement refresh requested only /copilot_internal/user; token, MCP, and managed-settings caches were reused
• reload made zero managed-settings requests
• Developer: Sync Account Policy refreshed entitlement, token, managed-settings, and MCP data exactly once each
• the managed-settings 404 stopped after the first distinct session and was cached as “no policy”

Council review

GPT-5.5, Claude Opus 4.6, and GPT-5.3-Codex unanimously found that making forceResolveEntitlement fully cache-aware would regress quota-reset, dashboard, and post-upgrade freshness for up to one hour. The current implementation fixes that with a single entitlement-only refresh option and focused regression coverage.

Validation

• npm run hygiene
• npm run compile (zero errors)
• npm run valid-layers-check
• ./scripts/test.sh --run src/vs/workbench/services/accounts/test/browser/defaultAccount.test.ts --run src/vs/workbench/services/chat/test/common/chatEntitlementService.test.ts --run src/vs/workbench/services/policies/test/browser/accountPolicyGateContribution.test.ts (59 passing)

[Copilot]

Copilot review overview

Review tier: Balanced
Findings: 1

New issues introduced by this change (1)

Severity	Finding
	src/​vs/​workbench/​services/​accounts/​browser/​defaultAccount.ts — preserveManagedSettingsCache is ineffective in the real refresh path when…

What changed in this PR

Reduces redundant managed-settings requests during account and entitlement refreshes.

Changes:

• Adds managed-settings cache preservation for entitlement refreshes.
• Deduplicates matching authentication sessions.
• Stops session fallback after managed-settings 404 responses.

File	Description
src/​vs/​platform/​defaultAccount/​common/​defaultAccount.ts	Adds refresh options for cache preservation and retries.
src/​vs/​workbench/​services/​accounts/​browser/​defaultAccount.ts	Updates caching, session matching, and request fallback.
src/​vs/​workbench/​services/​accounts/​test/​browser/​defaultAccount.test.ts	Tests caching, deduplication, and 404 handling.
src/​vs/​workbench/​services/​chat/​common/​chatEntitlementService.ts	Preserves managed-settings cache during entitlement refresh.

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[joshspicer]

Completed a deterministic launch validation matrix against the current PR implementation using scripts/mock-policy-server with all four account endpoints mocked.

Passed scenarios

• wrong endpoint scope is not reused
• missing and stale caches make exactly one managed-settings request
• fresh cached 404, empty 200, and policy-bearing 200 make zero managed-settings GETs on reload
• 404 is cacheable and does not fan out across overlapping OAuth scope alternatives
• explicit entitlement refresh calls only /copilot_internal/user
• forceRefresh: true calls entitlement, token, managed settings, and MCP once each
• cached forceRemoteSettingsRefresh bypasses freshness once per reload
• 500, malformed JSON, disconnect, and timeout remain fail-closed
• same-process automatic retry is suppressed after forced-refresh failure
• explicit retry bypasses the failure guard with one new application request
• 429 activates 60-second backoff; no automatic or explicit wire request occurs during backoff
• 466 blocks, persists compatibility state, and a later 200 reload revalidates and recovers
• broad OAuth session matching all three accepted scope alternatives is selected once
• forced 401 uses only the selected session

Transport caveat

An immediate socket reset produced one application-level fetch and one Failed to fetch result, but Chromium retried the idempotent GET twice underneath fetch, so the mock server saw three near-simultaneous wire hits. This is bounded browser transport behavior—not auth-session fallback or an application retry loop. Normal HTTP responses (401/404/429/466/500) each produced one wire GET.

Full evidence: session launch validation report.

[Copilot]

Copilot review overview

🟢 Approval recommended

Review tier: Balanced
Findings: 1

Pre-existing issues (1)

Severity	Finding
	src/​vs/​workbench/​services/​accounts/​browser/​defaultAccount.ts — preserveManagedSettingsCache is ineffective in the real refresh path when… View comment

[Copilot]

Copilot review overview

🟢 Approval recommended

The focused implementation preserves fail-closed policy behavior and has appropriate regression coverage.

Review tier: Balanced
Findings: None

Issues resolved since last review (1)

Severity	Finding
	src/​vs/​workbench/​services/​accounts/​browser/​defaultAccount.ts — preserveManagedSettingsCache is ineffective in the real refresh path when… View resolved comment

[github-actions]

Screenshot Changes

Base: c89cda63 Current: 0cb45ca0

Changed (1)

chat/aiCustomizations/aiCustomizationManagementEditor/McpServersSearch/Light

Before	After

[joshspicer]

Re-ran the full deterministic E2E matrix on the current reduced head 39f097e2737 using authenticated Code OSS Dev plus mock-policy-server.

Test	Proof observed
Wrong endpoint scope	Production-scoped cache was rejected; localhost received exactly one managed-settings GET.
Missing cache	Deleted defaultAccount.cachedPolicyData in the isolated profile; next launch produced one 404 GET.
Initial 404	Exactly one GET; no duplicate request despite the OAuth session matching all three accepted scope alternatives.
Fresh cached 404 reload	After clearing the mock log, reload produced only two /user requests and zero managed-settings/token/MCP requests.
Entitlement-only refresh	The second startup refresh added only /user; token/MCP/managed-settings counts did not increase.
Full force sync	Developer: Sync Account Policy produced exactly one /user, token, managed-settings, and MCP GET.
Empty 200 cache	One 200 sync request; next reload produced zero managed-settings GETs.
Policy 200 cache	One 200 sync request; renderer logged policy applied; next reload produced zero managed-settings GETs.
Stale cache	Aged only managedSettingsFetchedAt beyond one hour; next launch produced exactly one 200 GET.
Forced freshness success	Seeded forceRemoteSettingsRefresh; reload produced exactly one 200 managed-settings GET.
Forced 500 failure	Reload produced one 500; renderer restricted the policy gate and logged automatic retry suppression.
Explicit retry	Sync after the 500 added exactly one second managed-settings GET.
429 backoff	One 429 GET; explicit Sync during the 60-second backoff did not add another server hit.
466 recovery	One 466 blocked; after dismissing the compatibility modal and switching to 200, the next real reload produced one recovery GET.
Malformed JSON	One 200 malformed response; renderer logged parse failure and remained fail-closed.
Timeout	One status-0 server entry; the next stage began about five seconds later and the gate remained restricted.
Normal and forced 401	The broad OAuth session produced one 401 despite matching all scope alternatives; separately seeded forced freshness also produced one selected-session 401.
Immediate disconnect	Renderer/network logs showed one application fetch and one Failed to fetch; Chromium retried the reset idempotent GET twice, so the mock server saw three status-0 wire hits. No app/session retry occurred.

Result: 16 exact passes, 1 pass with the documented Chromium transport caveat. All mock wiring, processes, profiles, and caches were cleaned afterward; the worktree remains clean.

[joshspicer]

Completed a controlled endpoint-load A/B between the exact pre-PR merge base c89cda63706 and this PR using separate compiled worktrees, the same authenticated profile, the same warmed cache for hot cases, and identical mock-policy-server responses.

Scenario	Pre-PR total	PR total	Delta
Cold start / new endpoint scope / 404	10	3	-7
Hot process start / cached 404	7	2	-5
Hot window reload / cached 404	7	2	-5
Explicit force sync / 404	6	4	-2
Governed reload / successful required refresh	6	3	-3
Governed reload / required refresh returns 500	5	3	-2
Explicit force sync / 401	6	4	-2

Endpoint-level result:

• /copilot_internal/user: unchanged in every scenario
• /v2/token: equal or lower
• /managed_settings: equal or lower
• MCP registry: equal or lower
• positive endpoint deltas: 0

Key hot-reload comparison:

• pre-PR: /user 2, token 1, managed settings 3, MCP 1
• PR: /user 2, token 0, managed settings 0, MCP 0

Key governed-500 comparison after equal settled windows:

• pre-PR: /user 2, token 1, managed settings 1, MCP 1
• PR: /user 2, token 0, managed settings 1, MCP 0

The release cherry-pick #333863 has the same stable production patch ID (6755743a8478e5af6462620dbefa1121a8375791), so these production load deltas apply there as well.