Await session state before computing the customization migration hint

[Martin Aeschlimann (aeschli)]

Fixes #334953
Fixes #334553

Problem

The customization migration hint is missing on the first request of a new chat, for every Agent Host harness (verified with Copilot, Claude and Codex). Sending a second message in the same chat immediately shows the correct hint, and the Customizations overview shows the correct counts even before any request.

Cause

Both the hint and the overview use the same ICustomizationMigrationService.computeMigration(...), so this is not a difference in candidate discovery — it is a race on when the shared computation reads session state.

provideSourceFolders() resolves migration destinations from IAgentHostCustomizationService.getCustomizations(), which reads an AHP subscription synchronously:

customizations: sessionState?.customizations ?? [],

IAgentSubscription.value is documented as undefined until the first snapshot arrives, and _ensureSessionStateSubscription creates the subscription on demand — so the first read after creation always yields undefined, which the ?? [] collapses into "no customizations".

Subscriptions are keyed by the chat UI resource. On first send, _materializeUntitledSession() swaps the untitled resource (agent-host-PROVIDER:/untitled-<uuid>) for a freshly minted real resource. The hint then runs against that brand-new resource, so a subscription is created at that instant, has no snapshot, and every migration candidate is filtered out — silently, indistinguishable from "nothing to migrate".

Anything reading later (the reactive overview, the second request) sees the arrived snapshot, which is why only the first request is affected. It also explains why the symptom looks intermittent: when the subscription happens to be warm, the hint appears.

Fix

Add whenCustomizationsReady(sessionResource, token) to IAgentHostCustomizationService and await it in provideSourceFolders(), so one-shot callers can distinguish "not loaded yet" from "no customizations".

• WorkbenchAgentHostCustomizationService waits for the subscription's first snapshot (an Error also counts as settled).
• The base and null implementations resolve immediately; their targets are backed by already-materialized provider state.
• getCustomizations() stays synchronous — reactive UI should keep reading the current value and re-rendering on onDidChangeCustomizations.

The wait is bounded (2s) and cancellable: the chat request path awaits the hint in a blocking Promise.all before sending the user's message, so an unbounded wait would risk delaying the first message. On timeout the caller falls back to today's behaviour.

This mirrors the existing readiness pattern in this area — computeMcpServerMigration() already does await scope.whenResolved() for the MCP half of the same service.

Validation

• New unit tests cover the deferred-then-resolved path, the already-loaded path, and the subscription-failure path.
• agentHostCustomizationService.test.ts, customizationMigrationServiceImpl.test.ts, remoteAgentHostCustomizationHarness.test.ts: 26 passing.
• npm run typecheck-client clean.
• Verified live in a dev build: a fresh Copilot chat now shows Found 1 user customization file that is present but not used by Copilot and could be migrated. on the first message.

Note: #334938 / #334942 is a separate Claude-specific gap (missing destinations on every request). That fix is still needed; this one addresses the first-request timing for all harnesses.

[Copilot]

Copilot review overview

🟡 Changes recommended

Repeated per-type waits can delay the first request for roughly six seconds rather than the intended two-second maximum.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review tier: Balanced
Findings: 1 · 1

New issues introduced by this change (2)

Severity	Finding
	src/​vs/​workbench/​contrib/​chat/​browser/​agentSessions/​agentHost/​agentCustomizationItemProvider.ts — The 2-second bound is applied once per source-folder type, not once per hint. createFileMigration…
	src/​vs/​workbench/​contrib/​chat/​browser/​agentSessions/​agentHost/​agentHostCustomizationService.ts — This contract says resolution guarantees a real snapshot, but the implementation also resolves on…

What changed in this PR

Fixes first-request customization migration hints by awaiting Agent Host session-state hydration.

Changes:

• Adds bounded, cancellable customization readiness.
• Awaits readiness before resolving migration folders.
• Adds readiness tests and updates a remote harness mock.

File	Description
agentHostCustomizationService.test.ts	Tests snapshot and failure readiness paths.
agentHostCustomizationService.ts	Adds the readiness API and implementation.
agentCustomizationItemProvider.ts	Awaits readiness before reading customizations.
remoteAgentHostCustomizationHarness.test.ts	Implements the new API in the test mock.

---

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

[Martin Aeschlimann (aeschli)]

Good catch — the per-call deadline was applied once per source-folder type, not once per hint.

createFileMigration queries provideSourceFolders once per target prompt type in a sequential loop, and the ConfiguredLocations category spans agent + instructions + skill, so a subscription that never hydrated could block the first message for roughly three deadlines (~6s) rather than one.

Fixed by memoizing the wait on the session-state subscription entry (ISessionStateSubscriptionEntry.readiness), so every source-folder query behind a hint — and the categories that run in parallel — join the same bounded wait. Two details worth calling out:

• A new subscription generation starts with no memo, and _ensureSessionStateSubscription replaces the entry when the backend session changes. The untitled → real rebind that causes this bug therefore still gets a full wait.
• Each caller races the shared wait against its own token, so one caller's cancellation cannot settle it for the others.

Added whenCustomizationsReady shares one bounded wait across every prompt-type query as the multi-type regression test. It asserts the listener count stops growing across repeated queries rather than using a wall-clock bound, which would be flaky on CI. Verified it genuinely catches the regression: with the memo removed it reports 4 instead of 2.

34 passing across the three affected suites; typecheck-client clean.