Made changes to how parameter.Value works#10354
Merged
Conversation
- Value now blocks (sync over async) waiting for value resolution if WaitForValueTcs is set. - Made GetValueAsync on ParameterResource public. - Changed most code outside of tests to use GetValueAsync instead of Value
Contributor
There was a problem hiding this comment.
Pull Request Overview
This PR ensures that parameter values are resolved consistently by making ParameterResource.Value block on async resolution, exposing GetValueAsync, and updating callers to use the async API.
- ParameterResource.Value now synchronously awaits the async resolution path
GetValueAsyncis made public and most callers switch from.Valueto.GetValueAsync(...)- Call sites in various builder extensions are updated to await parameter values
Reviewed Changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| src/Aspire.Hosting/ResourceBuilderExtensions.cs | Await URL parameter resolution in WithEnvironment |
| src/Aspire.Hosting/Orchestrator/ParameterProcessor.cs | Switched from Value to ValueInternal in parameter processing |
| src/Aspire.Hosting/ExternalServiceBuilderExtensions.cs | Expose async URL retrieval and adjust initial state |
| src/Aspire.Hosting/ApplicationModel/ParameterResource.cs | Made GetValueAsync public and unified Value implementation |
| src/Aspire.Hosting.Redis/RedisBuilderExtensions.cs | Use async resolution for Redis password parameter |
| src/Aspire.Hosting.MySql/MySqlBuilderExtensions.cs | Await MySQL password parameter in PhpMyAdmin setup |
| src/Aspire.Hosting.Azure/Provisioning/Provisioners/BicepProvisioner.cs | Use GetValueAsync for parameter-based resource group names |
Comments suppressed due to low confidence (1)
src/Aspire.Hosting/ApplicationModel/ParameterResource.cs:89
- New public API
GetValueAsyncwas introduced but there are no unit tests for it. Consider adding tests to cover waiting onWaitForValueTcsand the fallback toValueInternal.
public async ValueTask<string?> GetValueAsync(CancellationToken cancellationToken)
DamianEdwards
approved these changes
Jul 12, 2025
Contributor
Author
|
/backport to release/9.4 |
Contributor
|
Started backporting to release/9.4: https://github.com/dotnet/aspire/actions/runs/16240431419 |
This was referenced Jul 13, 2025
This was referenced Jul 28, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This was found while dogfooding the latest build with async parameter resolution. We were using ParameterResource.Value is many places and as a result those places did not properly wait for values to be resolved before continuing, they just failed. Now ParameterResource.Value calls
ParameterResource.GetValueAsync(...).GetAwaiter().GetResult(), which is not great, but is consistent. We need the sync and async versions to work exactly the same way to avoid inconsistent state.There's a risk with introducing deadlocks with this change for people that were using .Value before.
I'm working through tests now to make sure that does not happen in practice.👍🏾 If the Value is accessed before the TCS is set then it will throw an exception like it did before.Fixes #10352
Checklist