Closed afscrome closed 1 month ago
cc @mitchdenny
We could add some extra log messages here to make this clearer. Also related to https://github.com/dotnet/aspire/issues/5558
I'll work on this after #5515 merges in.
Related - when health checks fail, a failure
message shows up in the terminal logs, but nothing shows up within the aspire console. Would be nice if these health check failures could be shown in the console logs for resources waiting on them.
We can't clutter the console logs for a resources with health check logs (those logs will go away in the next PR), there would be multiple things writing to the output stream. We need another log stream to show health checks logs.
I was specifically thinking about including health check failures in the console logs during the Waiting phase to provide indication of the WaitFor progress. Although you probably don't need the full exception to indicate this. e.g. in the above example, the logs for the waiting
resource could show something like
INFO: Resource
test
healthcheck reportedunhealthy
. Will try again inx seconds
I do agree that including them after the resource has fully started will be spammy & confusing.
Should be fixed by #5842 which adds a WaitAnnotation
and makes log entries clearer about what is blocking startup of a particular resource.
Is there an existing issue for this?
Is your feature request related to a problem? Please describe the problem.
With the
WaitFor
implementation in main, it's hard to see what a resource is actually waiting on. Logs are logged when a resource starts waiting on a resource, but nothing gets logged once that wait is complete.In the following example, it looks like we're waiting for both
sql
andmigrator
, however we're actually only waiting onmigrator
assql
has started up.Similarly with a longer chain of dependencies, You may see that you're waiting on
B
, butB
is in turn waitign onC
(which could in turn be waiting onD
).Describe the solution you'd like
A quick solution is to include a log entry when a wait is complete
That would at least allow you to work out what is outstanding.
A slightly better solution would be if there was an easy way to see what was outstanding from a single place, without having to calculate across multiple log entries. Without adding additional UI, there's limited options with the append only logs - you could add a log along the lines of
Waiting on 2/3 dependencies - 'migrator' and 'foo' remain
log each time a dependency is removed. Even better is if this could include transitive dependencies, but that likely gets messy quickly.The ideal would be some kind of UI on the resource that could present the dependencies as some kind of tree which you could follow to see how far the dependencies have gotten.
Additional context
No response