Fix flaky SubLevelCommandNameShouldBeSentToTelemetry test on macOS

[MichaelSimons]

Summary

Fixes #54746

The SubLevelCommandNameShouldBeSentToTelemetry test was intermittently failing on the macOS arm64 CI leg (osx.15.arm64.open).

Root Cause

InstantiateCommand.ExecuteAsync dynamically adds template names (e.g., "console") as subcommands to the static Parser.RootCommand's NewCommand. This mutation persists for the process lifetime. When another test in the same xUnit process triggers template instantiation before this test runs, "console" becomes a registered subcommand — causing System.CommandLine to classify it as TokenType.Command instead of TokenType.Argument. The AllowListToSendVerbSecondVerbFirstArgument telemetry rule then reports subcommand="CONSOLE", argument="" instead of the expected argument="CONSOLE".

The intermittent nature is due to non-deterministic xUnit test ordering, which varies by platform/scheduler.

Fix

Parse against a fresh DotNetCommandDefinition() instance instead of the static Parser.RootCommand singleton. This guarantees the parser tree has not been mutated by prior template instantiations.

Testing

• Build verified locally
• The fix ensures deterministic behavior regardless of test execution order

[Copilot]

Pull request overview

This PR fixes intermittent failures in TelemetryFilterTests.SubLevelCommandNameShouldBeSentToTelemetry on macOS by avoiding reliance on the process-wide static CLI parser tree, which can be mutated by other tests (notably via template instantiation adding dynamic dotnet new subcommands).

Changes:

• Switch the test to parse using a freshly constructed DotNetCommandDefinition() instead of the static Microsoft.DotNet.Cli.Parser.RootCommand.
• Keep the existing Parser.ParserConfiguration so parsing behavior (POSIX bundling/response file handling) remains consistent with other tests.

[dsplaisted]

So Parser.Parse isn't thread-safe for us? Are there other tests that call the same API?

[MichaelSimons]

So Parser.Parse isn't thread-safe for us? Are there other tests that call the same API?

Parser.Parse itself is thread-safe — it doesn't mutate the parser tree. The issue is that InstantiateCommand.ExecuteAsync (line 250) mutates the static tree after parsing by calling args.NewOrInstantiateCommand.Subcommands.Add(templateCommandToRun). This adds template short names (like "console") as subcommands to the NewCommand.

In production this is fine because each CLI invocation is a separate process. But in-process during tests, if any test executes a dotnet new <template> command (not just parses), the static tree is permanently mutated for that process.

Other tests that call Parser.Parse (workload, tool, build, sdk check, etc.) are not affected because:

1. Their commands' subcommands are never dynamically mutated
2. The "new" command is the only one where InstantiateCommand adds subcommands at execution time

This specific test is the only one that parses ["new", "<template-name>"] and relies on the template name being classified as an Argument token. The workload/tool tests work because "install" is a statically-registered subcommand regardless of mutation.

[joeloff]

Are there other tests that follow a similar pattern that could be at risk?

[MichaelSimons]

Are there other tests that follow a similar pattern that could be at risk?

I did ask copilot and this was the only occurrence it found.