Consider disabling VersionCheckService in DistributedApplicationTestingBuilder
- Dominant language
- C#
- Stars
- 6.3k
- Forks
- 991
- Avg merge
- 2d 15h
- Merged PRs (30d)
- 196
Description
## Summary
The `VersionCheckService` background service is registered by `DistributedApplicationBuilder` and runs during tests that use `DistributedApplicationTestingBuilder`. When tests register their own `IInteractionService` (with `IsAvailable = true`), the version checker can race with the test by pushing an "Update now" `PromptNotificationAsync` interaction into the service before the test's expected interaction arrives.
This caused a flaky failure in `ExecuteCommandAsync_InteractiveWithoutArguments_PromptsForArguments` — the test read "Update now" from the interaction channel instead of the expected "My command":
```
Assert.Equal() Failure: Strings differ
Expected: "My command"
Actual: "Update now"
```
CI failure: https://github.com/microsoft/aspire/actions/runs/27994875612
Beyond the race condition, the version check makes an outbound HTTP request (via `dotnet package search`) to query NuGet feeds for the latest `Aspire.Hosting.AppHost` version. This is not ideal to run in the background during automated testing — it adds unnecessary network traffic, can slow down tests, and may fail or behave unpredictably in CI environments with restricted network access.
## Question
Should `DistributedApplicationTestingBuilder` (or `TestDistributedApplicationBuilder` in the test utilities) disable the version check by default? The version checker serves no purpose in unit/integration tests and can interfere with tests that use `IInteractionService`.
Currently, individual test classes must opt out by setting `builder.Configuration[KnownConfigNames.VersionCheckDisabled] = "true"` (as done in `BrowserLogsBuilderExtensionsTests` and now `ResourceCommandServiceTests` via #18418). This is easy to forget and leads to intermittent failures that are hard to diagnose.
Options:
1. **Disable in `DistributedApplicationTestingBuilder`** — set `ASPIRE_VERSION_CHECK_DISABLED=true` by default in the testing builder so all test consumers get the right behavior automatically.
2. **Keep the current approach** — individual test classes disable it when needed.
3. **Make `IsAvailable` default to `false` in test scenarios** — the default `IInteractionService` in test mode could report `IsAvailable = false`, which would cause the version checker to skip automatically.
Option 1 seems like the safest default since version checking has no value during testing.
Contributor guide
Research direction
Start with DistributedApplicationTestingBuilder and TestDistributedApplicationBuilder, then inspect how KnownConfigNames.VersionCheckDisabled is set. Review BrowserLogsBuilderExtensionsTests and ResourceCommandServiceTests for existing opt-outs, and run ExecuteCommandAsync_InteractiveWithoutArguments_PromptsForArguments to verify that the version-check interaction no longer races with the expected prompt.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- testing
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100