Waiting for health status of a stopped resource

[JamesNK]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

WaitUntilHealthyAsync will stop waiting, or not attempt to wait, if the resource is in an exited/finished state:

aspire/src/Aspire.Hosting/ApplicationModel/ResourceNotificationService.cs

Lines 134 to 154 in 9e5deba

	if (snapshot.State?.Text == KnownResourceStates.FailedToStart)
	{
	resourceLogger.LogError(
	"Dependency resource '{ResourceName}' failed to start.",
	dependency.Name
	);
	throw new DistributedApplicationException($"Dependency resource '{dependency.Name}' failed to start.");
	}
	else if (snapshot.State!.Text == KnownResourceStates.Finished || snapshot.State!.Text == KnownResourceStates.Exited)
	{
	resourceLogger.LogError(
	"Resource '{ResourceName}' has entered the '{State}' state prematurely.",
	dependency.Name,
	snapshot.State.Text
	);
	throw new DistributedApplicationException(
	$"Resource '{dependency.Name}' has entered the '{snapshot.State.Text}' state prematurely."
	);
	}

It makes sense to stop waiting if resources can't be started again. I think this was written before we had start/restart commands.

Expected Behavior

Should WaitUntilHealthyAsync wait for a healthy status and ignore if the resource stops?

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version info

No response

Anything else?

No response

[JamesNK]

cc @davidfowl

[JamesNK]

Offline discussion:

If a resource is started and it must wait for a resource that is stopped/finished then there are only two options.

1. The started resource waits until the other resource is started again and becomes healthy, or
2. The started resource fails and enters a FailedToStart state. The user must start the waited on resource first, then try again.

Option 1 is a better user experience. We don't force people to understand the right order when starting multiple resources. However option 2 is useful for tests where we want tests to fail fast.

We could add a flag to control the behavior, with normal usage to be to wait (option 1) and tests are configured to fail (option 2).

[afscrome]

We could add a flag to control the behavior, with normal usage to be to wait (option 1) and tests are configured to fail (option 2).

Could DistributedApplicationOptions.DisableDashboard be used as that flag? If the dashboard is present, wait for a future start. If dashboard isn't, fail.

[davidfowl]

I think we would add a new flag,

[davidfowl]

I'm going to work on this in 9.1. There will be a default wait behavior determined by if the dashboard is enabled or not. It'll be possible to override it on the per call basis (ConfigureAwait 😄 )