Add requestKind to chat response telemetry events

[kevin-m-kent]

Emit a new requestKind property on response.success, response.cancelled, and response.error telemetry events. Values are 'background', 'subagent', or 'normal', derived from the same requestKindOptions that already sets the outgoing X-Interaction-Type header in CAPI requests.

Motivation

Today we can tell from telemetry whether a chat request was initiated by the user vs. an agent tool call (via initiatorType), but we can't distinguish which agent requests are background (speculative/system) vs. subagent (spawned by a parent agent) vs. normal primary-turn requests. That signal is already on the wire as the X-Interaction-Type header, but it isn't logged client-side. This makes it hard to slice perf / success metrics by request kind.

Changes

extensions/copilot/src/extension/prompt/node/chatMLFetcherTelemetry.ts

• Adds requestKindOptions to IChatMLFetcherSuccessfulData, IChatMLFetcherCancellationProperties, IChatMLFetcherErrorData.
• Emits requestKind: requestKindOptions?.kind ?? 'normal' on response.success, response.cancelled, response.error.
• Adds the property to each event's __GDPR__ schema (classification SystemMetaData, purpose FeatureInsight).

extensions/copilot/src/extension/prompt/node/chatMLFetcher.ts

• Threads requestKindOptions (already destructured at the top of fetchMany) into all five call sites: the success, cancel, and error calls in fetchMany and _retryAfterError, plus the new processSuccessfulResponse parameter.

Notes

• BYOK (Anthropic / Gemini native) providers declare initiatorType in their response.success GDPR schema but don't actually emit it today; intentionally leaving BYOK out of this PR to keep it scoped to the CAPI path.
• No behavior change; telemetry-only.

[Copilot]

Pull request overview

This PR extends Copilot chat response telemetry to include a requestKind dimension ('normal' | 'background' | 'subagent') on the CAPI path, derived from existing requestKindOptions that already influence the X-Interaction-Type header. This enables slicing success/cancel/error metrics by request kind without changing runtime behavior.

Changes:

• Adds requestKindOptions to the telemetry payload interfaces and emits requestKind on response.success, response.cancelled, and response.error.
• Updates the GDPR schemas for the three events to include requestKind (SystemMetaData / FeatureInsight).
• Threads requestKindOptions through ChatMLFetcherImpl success/cancel/error telemetry call paths (including retry/error paths).

Show a summary per file

File	Description
extensions/copilot/src/extension/prompt/node/chatMLFetcherTelemetry.ts	Adds requestKind emission and GDPR schema entries for success/cancel/error response telemetry.
extensions/copilot/src/extension/prompt/node/chatMLFetcher.ts	Passes requestKindOptions through to telemetry senders and into processSuccessfulResponse.

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 0

[kevin-m-kent]

@roblourens curious what you think of this. We are looking to filter out background requests in a robust way for our A/Bs, rather than maintain a list of sources. Copilot seems to think that this header for background interaction type never actually fires, but I'm suspicious of that claim.

[kevin-m-kent]

Summary

Goal

Classify every Copilot chat request with a requestKind for telemetry and align the X-Interaction-Type header sent to CAPI with the server's documented taxonomy, so each request surface — primary user turns, subagent calls, background utility work (title gen, commit messages, intent detection, language-model passthroughs, tool-call healers, etc.), summarization, and NES — is independently distinguishable in CAPI logs and our telemetry.

Changes

Telemetry (chatMLFetcherTelemetry.ts)

• Added two properties to the chat response telemetry events:
  • requestKind — the resolved conversation-* value (matches what's sent on the wire).
  • parentRequestId — links a sub-call (subagent invocation, summarization, intent detection, healer retry, etc.) to the user turn that spawned it. Sourced from IChatMLFetcher options threaded through IMakeChatRequestOptions.
• These were already on panel.request for the user-facing turn but were missing from response.success, response.cancelled, and response.error. Coverage is now uniform across all three terminal events, so a turn with a cancellation or filter/error mid-cascade can still be reconstructed.

RequestKind (networking.ts)

• Introduced a RequestKind const object — three values that map 1:1 to the server's X-Interaction-Type taxonomy:
  • MainAgent → resolved from ChatLocation (conversation-panel / conversation-inline / conversation-edits / conversation-agent / conversation-other / etc.)
  • Subagent → conversation-subagent
  • Background → conversation-background
• Added a resolveInteractionType(kind, intent) helper used by both the websocket and HTTP fetcher paths so X-Interaction-Type is always sent and always matches the telemetry value.

Inverted default (chatMLFetcher.ts)

• Requests that don't explicitly opt in to a kind now classify as Background (previously fell through to mainagent/normal). This correctly labels ~40 utility callers in telemetry without per-site annotation.
• Primary user-initiated paths explicitly opt in to MainAgent: defaultIntentRequestHandler, inlineChat2Intent, newNotebookIntent (×3), setupTestsInvocation (×2).

Subagent coverage

• executionSubagentToolCallingLoop now opts in to Subagent (was missing; companion searchSubagentToolCallingLoop already had it).

Summarization & NES rely on ChatLocation (no dedicated kind)

• Summarization (summarizer.ts, summarizedConversationHistory.tsx, agentIntent inline summarization): MainAgent + ChatLocation.Agent → conversation-agent. (summarizer.ts and summarizedConversationHistory.tsx had their location updated from Panel/Other → Agent so the fallthrough lands on the right value.)
• NES (xtabProvider, xtabNextCursorPredictor): MainAgent with existing ChatLocation.Other → conversation-other.

Net effect

• Every request emits a stable requestKind, parentRequestId, and conversationId on its response telemetry event (success / cancelled / error) and a matching X-Interaction-Type header on the wire.
• Utility/helper callers that previously sent no header (websocket path) or a misleading conversation-panel (HTTP path) now correctly send conversation-background.
• Main-agent, subagent, summarization (conversation-agent), inline-edit, NES (conversation-other), and panel/ask requests are each distinguishable in CAPI logs and in our telemetry, and sub-calls can be joined back to their parent turn / conversation regardless of outcome.