Closed mitchdenny closed 3 weeks ago
Note that this feature may not ship in 8.2 - work will be done in 8.2 but it probably won't be complete.
There may be some interaction between what we want to do here and #5234 (issue) #5223 (PR).
@mitchdenny I'm assuming this is not going to make it into 8.2 (meaning it is not blocking)
Not blocking. But we probably want this in for 8.2: https://github.com/dotnet/aspire/pull/5359
The milestone was updated to 9.0 - does that mean it's not going to make it into a LTS version of .NET until Q4 2025? Can we get a backport of the feature for .net 8.0? Many companies have a "LTS only" policy and this feature is a major blocker.
That is the current plan. As we got into this we realized that WaitFor(...)
really needs to perform some kind of health check on the resource that was deployed to ensure that its actually available to handle traffic (not just that it merely started).
That means that we need to add health check mechanisms to all of our Aspire.Hosting.* packages which is a big step up in the dependency graph for hosting packages. Its probably not something we would want to rush into an 8.x release or even backport given the some of the churn that would involve.
Aspire 9.x is going to be compatible with .NET 8.
Principal feature work for this is now in. We have a few trailing issues:
This is done
Big "Thank you!" to everyone involved in getting this through!
The .WaitFor(...) dependicies will be available in Aspire .net 9 release?
thanks
The purpose of this issue is to bring together the various threads/issues/discussions about a new API that we want to add to the .NET Aspire AppHost/AppModel that allows developers to express startup dependencies between resources. The most recent spike/prototype of this feature was by @davidfowl here:
https://github.com/davidfowl/WaitForDependenciesAspire/blob/389f02daf2a3903924875c601dc300371aa99e27/WaitForDependencies.AppHost/Program.cs#L19
This issue is not a formal API proposal (we'll create one of those separately). But the high level of the API is this:
This would create a new annotation in the app model which mechanisms like the
ApplicationExecutor
(internal) would honor (@davidfowl's prototype exploits environment callbacks so we would be shifting to something more explicit).David's prototype also has a
WaitForCompletion(...)
method and we are also experimenting withWaitForText(...)
APIs in some of our internal testing code which are also good candidates for inclusion in this overall feature.Finally, we may want this feature to integrate in some way with health checks so that
WaitFor(...)
... when health checks are present waits for the checks to become healthy before allowing the dependent resource to start up.