Problem: Terminal activation can be recorded as successful even when its shell command times out, fails, or provides no evidence that it completed. This can leave the extension showing an environment as activated when the terminal is not actually using it. It also prevents us from measuring whether activation failures contribute to reports of unpredictable terminal behavior.
Proposed change: Make shell-command execution return a distinct outcome: succeeded (matching completion event with exit code 0), failed (nonzero exit code or execution error), timedOut, or unknown (completion without an exit code). Treat a timeout as unconfirmed, since the command may still complete later. Update the extension's activated/deactivated state only on confirmed success. Record legacy sendText activation separately as unverified, because that path cannot confirm command completion.
Emit an outcome event for activation and deactivation attempts with:
- Properties: operation (
activate/deactivate), outcome, execution method (shellIntegration/sendText), shell category, and a bounded trigger category where known (for example, automatic terminal-open versus explicit command).
- Measure: elapsed time in milliseconds.
Do not include interpreter or workspace paths, environment names, command text, terminal output, or raw error messages. Use the existing typed telemetry and privacy-classification conventions.
Why this helps users: We can measure how often activation is confirmed, fails, times out, or cannot be verified—and segment those rates by shell and activation route. That gives us evidence to prioritize fixes for the terminal-startup and unexpected-activation complaints, rather than relying on an "activated" UI state that may be false.
Acceptance criteria:
- A successful shell command updates activation state and emits
succeeded.
- A nonzero exit code, execution error, timeout, or missing exit code does not report confirmed success or change activation state; each emits its distinct outcome.
- Failed or unconfirmed deactivation does not incorrectly clear the existing activation state.
- Legacy
sendText attempts are identified as unverified, not succeeded.
- Tests cover success, nonzero and missing exit codes, execution errors, timeout, a late completion after timeout, and deactivation failure.
- The telemetry schema contains only bounded, non-sensitive properties and a duration measure.
The current false-positive path is in src/features/terminal/terminalActivationState.ts: the timeout settles the wait as though the command completed, while activate marks the terminal activated after that wait.
Problem: Terminal activation can be recorded as successful even when its shell command times out, fails, or provides no evidence that it completed. This can leave the extension showing an environment as activated when the terminal is not actually using it. It also prevents us from measuring whether activation failures contribute to reports of unpredictable terminal behavior.
Proposed change: Make shell-command execution return a distinct outcome:
succeeded(matching completion event with exit code0),failed(nonzero exit code or execution error),timedOut, orunknown(completion without an exit code). Treat a timeout as unconfirmed, since the command may still complete later. Update the extension's activated/deactivated state only on confirmed success. Record legacysendTextactivation separately asunverified, because that path cannot confirm command completion.Emit an outcome event for activation and deactivation attempts with:
activate/deactivate), outcome, execution method (shellIntegration/sendText), shell category, and a bounded trigger category where known (for example, automatic terminal-open versus explicit command).Do not include interpreter or workspace paths, environment names, command text, terminal output, or raw error messages. Use the existing typed telemetry and privacy-classification conventions.
Why this helps users: We can measure how often activation is confirmed, fails, times out, or cannot be verified—and segment those rates by shell and activation route. That gives us evidence to prioritize fixes for the terminal-startup and unexpected-activation complaints, rather than relying on an "activated" UI state that may be false.
Acceptance criteria:
succeeded.sendTextattempts are identified asunverified, notsucceeded.The current false-positive path is in
src/features/terminal/terminalActivationState.ts: the timeout settles the wait as though the command completed, whileactivatemarks the terminal activated after that wait.