Skip to content
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

Closed
1 task done
afscrome opened this issue Sep 5, 2024 · 7 comments · Fixed by #5842
Closed
1 task done

Hard to see what WaitFor is really waiting on #5557

afscrome opened this issue Sep 5, 2024 · 7 comments · Fixed by #5842
Labels
area-app-model Issues pertaining to the APIs in Aspire.Hosting, e.g. DistributedApplication
Milestone

Comments

@afscrome
Copy link
Contributor

afscrome commented Sep 5, 2024

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.

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 and migrator, however we're actually only waiting on migrator as sql has started up.
image

Similarly with a longer chain of dependencies, You may see that you're waiting on B, but B is in turn waitign on C (which could in turn be waiting on D).

Describe the solution you'd like

A quick solution is to include a log entry when a wait is complete

2024-09-05T19:16:18 Waiting for resource 'sql' to enter the 'Running' state.
2024-09-05T19:16:19 Waiting for resource 'migrator' to complete.
2024-09-05T19:16:20 Finished waiting for resource 'sql' to enter the 'Running' state.

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

@dotnet-issue-labeler dotnet-issue-labeler bot added the area-app-model Issues pertaining to the APIs in Aspire.Hosting, e.g. DistributedApplication label Sep 5, 2024
@davidfowl
Copy link
Member

cc @mitchdenny

@davidfowl davidfowl added this to the 9.0 milestone Sep 5, 2024
@mitchdenny
Copy link
Member

We could add some extra log messages here to make this clearer. Also related to #5558

@mitchdenny
Copy link
Member

I'll work on this after #5515 merges in.

@afscrome
Copy link
Contributor Author

afscrome commented Sep 9, 2024

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.
image

@davidfowl
Copy link
Member

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.

@afscrome
Copy link
Contributor Author

afscrome commented Sep 9, 2024

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 reported unhealthy. Will try again in x seconds

I do agree that including them after the resource has fully started will be spammy & confusing.

@mitchdenny
Copy link
Member

Should be fixed by #5842 which adds a WaitAnnotation and makes log entries clearer about what is blocking startup of a particular resource.

@github-actions github-actions bot locked and limited conversation to collaborators Oct 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-app-model Issues pertaining to the APIs in Aspire.Hosting, e.g. DistributedApplication
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants