Copilot OTel reload prompt loops when managed settings resolve after activation

[digitarald]

Summary

Copilot Chat can show an OTel reload notification after every window reload or full application restart when managed settings resolve after the extension has already constructed its OTel service.

The confirmed notifications were:

• Copilot OTel settings changed - a reload is required for the change to take effect.
• after changing the local endpoint for diagnosis: Copilot OTel endpoint will change to … after reload.

Selecting Reload Window reproduces the same startup ordering, so the notification loops instead of applying the managed configuration.

Environment

• VS Code Insiders, release/1.140
• Commit 2dfd3b41fbc30a7270f0b84db51d67ab7568ebe3
• Copilot OTel was already explicitly enabled locally
• Managed Copilot settings were applied through the account-policy path

Runtime evidence

Initial run

18:12:05.453  Extension host starts, PID 9104
18:12:15.957  [DefaultAccount] Managed settings applied
~18:12:16.5  OTel stale-config check shows the generic reload notification
18:12:26.562  Window reload begins
18:12:27.630  New extension host starts, PID 18296
18:12:30.313  [DefaultAccount] Managed settings applied again
~18:12:30.8  The notification appears again

After a full application restart

18:45:42.181  Fresh Agent Host process starts
18:45:42.254  Fresh extension host starts, PID 14988
18:45:46.594  [DefaultAccount] Managed settings applied
~18:45:47.1  OTel shows the reload notification again

For the second run, the local OTel endpoint had intentionally been changed. The endpoint-specific notification proves that the managed endpoint became visible only after OTel initialization.

The Agent Host process itself started once per application run and was not the source of the notification.

Root cause

The Copilot extension constructs IOTelService once from IOTelConfigResolver.activeResolution. OTelStaleConfigMonitor later compares the current resolution with that startup snapshot.

When managed settings arrive late, the effective configuration drifts. Because OTel was already explicitly enabled locally, this branch applies:

if (active.hasEnterpriseSettings || active.config.enabledExplicitly || !isPolicyEnabledOtlp(current)) {
    // promptReload(...)
}

This occurs before the guarded automatic extension-host recovery path. The prompt offers workbench.action.reloadWindow, but reloading the window restarts account-policy initialization, causing managed settings to arrive late again.

The per-session automatic-restart guard is therefore not involved in this loop.

Relationship to previous work

• Copilot managed OTel policy can be missed during extension activation #336102 identified the managed OTel initialization race.
• Draft configuration: stabilize managed Copilot OTel startup #336156 / commit bea10f45f67 attempted to stabilize startup using the early core policy owners, but was closed as superseded.
• Fix Enterprise Managed OTel Race in Copilot Extension #336701 added restart-based late-policy recovery and closed Copilot managed OTel policy can be missed during extension activation #336102.

#336701 intentionally routes already-enabled OTel configurations to an opt-in reload. The logs above show that a window reload is not a successful recovery action when the account-managed settings pipeline resolves after extension activation on every launch.

Expected behavior

Once managed OTel settings resolve, Copilot should apply them without entering a reload loop. No telemetry-producing Copilot work should continue indefinitely with the stale startup configuration.

Potential directions

Any complete fix should cover managed-settings data that arrives after service construction, not only late registration of extension policy references. Options include:

1. await an account-managed-settings readiness barrier before constructing OTel;
2. make the extension and embedded runtime OTel pipeline safely reconfigurable/lazily initialized; or
3. restart only the extension host after policy settles, preserving the renderer's resolved account-policy state, instead of reloading the window.

At minimum, the informational drift path should not offer a recovery action that deterministically recreates the same race.

Diagnostics gap

The informational prompt path does not log describeOTelConfigDrift(active.config, current.config). Logging bounded field names only—not values—would make future incidents diagnosable without exposing collector URLs, headers, or other sensitive configuration.

🤖 Posted by GitHub Copilot on Harald's behalf.

[digitarald]

Additional evidence from a later Insiders Agent Host debug-log export with the endpoint-specific reload prompt:

• The renderer records AccountPolicyGate as restricted with reason=managedSettingsRefresh at 19:45:57.182, 19:45:57.971, and 19:45:59.164 (local time), then inactive at 19:45:59.753. This supports the issue's startup-ordering RCA: account-managed policy is not settled throughout activation.
• A possible additional route through the same prompt branch is the temporary account-policy gate. Restricted policy values fall back to false/empty strings; the extension's OTel resolver treats defaults that differ from schema defaults as hasEnterpriseSettings. If OTel snapshots those provisional defaults, the monitor's active.hasEnterpriseSettings || active.config.enabledExplicitly branch prompts for a reload instead of attempting automatic extension-host recovery. A local reproduction using the production resolver/monitor with provisional restricted values followed by managed values produced the endpoint reload prompt on each of two independent simulated starts, without an automatic restart. The export does not contain the extension's active OTel snapshot, so this is a reproducible mechanism, not proof of which side of the || fired in this instance. The already-explicitly-enabled-local condition identified in the issue remains sufficient.
• Separately, the native Agent Host log at 02:46:14.707 UTC records resolved server+device managed policy including telemetry (serverFetchFailed=false); at 02:46:14.843 it reports OpenTelemetry configured from managed settings: exporter=otlp-http, source=github.copilot. The managed-settings self-fetch later reports serverResolution=Live, and the OTel SDK initializes and creates a session tracker at 02:46:15.286–.287. Thus the extension reload prompt does not mean that Agent Host failed to apply managed OTel settings. This bundle does not show the effective collector URL or an export acknowledgment, so it cannot establish delivery to the collector.
• The native process separately warns that OTEL_EXPORTER_OTLP{,_TRACES,_METRICS}_PROTOCOL=otlp-http is unrecognized and falls back to another protocol. That should be corrected to a supported wire-protocol value (http/json or http/protobuf) but is not the reload prompt. The failed to transition remote exporter ... Failed to get authentication token entry concerns remote session export, not the OTel collector.

For diagnosis, logging the startup snapshot's hasEnterpriseSettings/enabledExplicitly flags, the policy-gate state, and drift field names only at the prompt would disambiguate the two routes without logging endpoints or credentials.

[digitarald]

The crux for triggering this is "forceRemoteSettingsRefresh": true