Add `WaitForStart`

[afscrome]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Currently you can wait for a service to become healthy, or become healthy. In some cases it would also be beneficial to wait until a service starts. This is particularly true for initalisation type code that may be required to run before the health checks can pass.

Describe the solution you'd like

I'd like to see some WaitForStart methods, which mirror the existing WaitFor methods - the only difference is these only wait for the resource to enter the Running state, as opposed to waiting for health checks to pass. If a resource has no health checks defined, the two methods will behave identically.

namespace Aspire.Hosting;
public static class ResourceBuilderExtensions
{
    //...

    public static IResourceBuilder<T> WaitFor<T>(this IResourceBuilder<T> builder, IResourceBuilder<IResource> dependency) where T : IResourceWithWaitSupport
    public static IResourceBuilder<T> WaitFor<T>(this IResourceBuilder<T> builder, IResourceBuilder<IResource> dependency, WaitBehavior waitBehavior) where T : IResourceWithWaitSupport
    public static IResourceBuilder<T> WaitForCompletion<T>(this IResourceBuilder<T> builder, IResourceBuilder<IResource> dependency, int exitCode = 0) where T : IResourceWithWaitSupport

+   public static IResourceBuilder<T> WaitForStart<T>(this IResourceBuilder<T> builder, IResourceBuilder<IResource> dependency) where T : IResourceWithWaitSupport
+   public static IResourceBuilder<T> WaitForStart<T>(this IResourceBuilder<T> builder, IResourceBuilder<IResource> dependency, WaitBehavior waitBehavior) where T : IResourceWithWaitSupport

    //...
}

Additional context

This would align Aspire's wait for options with the conditions docker compose supports in it's depends_on

• condition: Sets the condition under which dependency is considered satisfied
  • service_started: An equivalent of the short syntax described above
  • service_healthy: Specifies that a dependency is expected to be "healthy"
    (as indicated by healthcheck) before starting a dependent
    service.
  • service_completed_successfully: Specifies that a dependency is expected to run
    to successful completion before starting a dependent service.

https://github.com/compose-spec/compose-spec/blob/main/05-services.md#depends_on

[mitchdenny]

Could possibly be another WaitBehavior enumeration value?

[maddymontaquila]

@afscrome do you think some of the eventing stuff would alleviate this? Or do you want it in the helper method? https://learn.microsoft.com/en-us/dotnet/aspire/app-host/eventing#resource-eventing

[mitchdenny]

I'm sympathetic to this request, although I'm trying to formulate a scenario in my head where WaitForStart is actually helpful. When I think about initialization tasks in my head they tend to fall into two categories - things that you need to run BEFORE you start the process (e.g. an npm install) or things you need to run after the resource is healthy (e.g. a data import to a database).

What you are proposing implies a third scenario - but I need an example to crystalize the need.

[afscrome]

It think my original use case was a resource needs initialisation logic to go healthy, but that initialisation logic requires the resource in question to be running. I forget the full context behind posting but I think I was translating some stuff from docker compose that used a depends on condition of service_started - sure there may have been a better way to do things, but at that time I was focused on translating the docker compose file and didn't want to re-invent whatever process was already in place.

The other main thing I can think of is anything that gets deployed as a Kubernetes sidecar - WaitForStart would allow you to match those semantics locally. Even if waiting for healthy may be the more
suitable event, Kubernetes doesn't have such an event so you may prefer to keep dev and prod closer by using WaitForStart() locally.

So I guess the main argument for WithStart() is to provide consistency with other orchestration tools (kubernetes and docker compose).

In terms of third scenarios, I'd consider that to be anything when you need to interact with the resource before it goes healthy. e.g. a web application that won't go healthy until you install a license. That license can only be installed via an API hosted by the resource itself, meaning that BEFORE the resource starts is too early, but waiting for healthy will only succeed if you take manual action to install the license. (At which point, there's no need to automate the process). Admittedly WaitForStart() isn't the perfect event for this case as you'll still have to implement retry logic etc. as you need to wait for the application to start up, but I'm not sure what else you can do. @maddymontaquila if this initialisation can be done via .Net code, eventing would be appropriate. But if such initialisation involves calling other CLI tools, then a dedicated resource with WaitForStart() may fit better. Ideally this is nothing you'd ever need with your own applications, but if you involve vendor / "Enterprise Software", they often have quirks like this you need to creatively work around.

[mitchdenny]

I think we would accept a PR for this one if anyone is interested. I think its potentially useful in some limited scenarios.