shuttle-hq
[Enhancement]: Add a loading bar when waiting for service to wake up
From: https://discord.com/channels/803236282088161321/1076126506323030017/1081194431346118708
A command that wakes the service from sleep shows a little loading bar like
(. . .) Waking/Restoring service...
and then, after a second or two, prints the usual output of the command.
Hi there! I would like to contribute to the project. Can i work on this?
That would be great @JosueMolinaMorales! To see some examples of where we do something similar, in cargo-shuttle/lib.rs we use a loading spinner for project_status, project_create, project_delete and stop, so it checks the state at regular intervals and then returns when the state is the expected one.
The difficulty here is that the project ... commands that hit the gateway endpoints (the deployer commands are routed through the gateway to the correct deployer, the project ... commands stop at gateway) don't wake the idle deployers, but it's the gateway that knows if the deployer is idle or not. So a command like cargo shuttle status can't check if the returned state is idle, if so try again.
I'll think about this and get back to you, but feel free to get started if you see a way forward, and feel free to ask questions if you need clarification.
So my understanding at the moment is when the project is in an idle state, and someone runs the status command, the api returns an error? but what is displayed to the user is: No deployment is currently running for this service No resources are linked to this service but the api actually wakes the project up, so when the user hits status again it displays the normal output?
If the gateway receives a request that should be routed to a deployer (like status or logs) and that deployer (project) is idled, it should try to start it and await that before routing the request through. However, what I think is happening here is that while it does indeed wait for the deployer to start, the actual service you have deployed inside that deployer will not have started when the request is passed through. So it returns no deployment is currently running. So we'll likely need to do a bit of refactoring here to make this work as expected... I'll keep thinking about it and get back to you if I have a good idea, but in the meantime don't hesitate to keep asking questions in this issue. :slightly_smiling_face:
Here is the handler on gateway that routes requests to deployers, by the way: https://github.com/shuttle-hq/shuttle/blob/main/gateway/src/api/latest.rs#L187-L201
Marking this as blocked since it likely requires service health checks (which is in progress).