-
Notifications
You must be signed in to change notification settings - Fork 543
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hard to see what WaitFor
is really waiting on
#5557
Comments
cc @mitchdenny |
We could add some extra log messages here to make this clearer. Also related to #5558 |
I'll work on this after #5515 merges in. |
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
I do agree that including them after the resource has fully started will be spammy & confusing. |
Should be fixed by #5842 which adds a |
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
The text was updated successfully, but these errors were encountered: