-
Notifications
You must be signed in to change notification settings - Fork 81
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
Salvo Support #247
Comments
Hi Gustavo To do anything at all about this, I would need:
That is the minimal amount of information that's needed for this, and frankly any bug report to a project. Without it I hope you understand that I'll have to close this issue as unactionable. Thank you |
Ready, I've done it 👍 |
That's not a debug log. That's an incomplete picture from your terminal.
What happens if you run One thing I notice, for example, is that if I put the salvo hello world in a project and run it, it produces no output at all. It's working, it just says nothing. As a consequence, running cargo watch exhibits the same behaviour. As a note, try not to edit your post over and over? That just means that I can't see when you change the text and the details change. For example, this sentence:
Wasn't there when I started writing this post. Now I really need that debug log. Please provide it as text, not as pictures. Please also note that cargo watch restarts the whole process, it does not do a "hot reload". I'm unsure if salvo has a facility for hot reloading -- if it does, you probably want to use that instead. Finally, my suspicion at this point is that this is an issue introduced by a recent macOS upgrade. Anecdotally, downgrading to cargo watch 8.1.1 may help:
|
|
Oh Sorry about that, that's not what I meant to do |
I just tested it, the same behavior occurs |
Well, from the log we can see that cargo watch is working. It's starting your server, and your server is listening.
Presumably you're then modifying something, and we can see cargo watch also responding to that:
It's sending a SIGTERM to your process. As that's the end of your log, I'm assuming that the process then "freezes". Are you by any chance handling signals in your app? If you're not responding to SIGTERM by quitting, then that would behave like you're seeing. |
You're right, but I don't handle any signal in my app, not sure how to do it use salvo::prelude::*;
#[handler]
async fn hello_world(res: &mut Response) {
res.render(Text::Plain("Hello world!"));
}
#[tokio::main]
async fn main() {
let router = Router::with_path("/").get(hello_world);
println!("Server running at port 3000");
Server::new(TcpListener::bind("127.0.0.1:3000"))
.serve(router)
.await;
} |
I have the same problem with my tonic grpc server, same logs "Sending signal SIGTERM to process group id" and then it hangs. i'm on macOS Ventura running cargo-watch@8.3.0. Also same behavior on 8.1.1.
|
mmkay, can you use watchexec and see how that behaves? If the issue persists, try with |
@passcod This doesn't work though
no-process-group doesn't work either. |
Hey @julienfouilhe @gustavocadev could you try using Rust 1.65 to install cargo-watch and try again? It might be this issue: #249 |
oh yes, It works now, something must have changed in the latest version of Rust I guess, thanks, should I close this issue? I thought it was a thing about Salvo, but it seems something more general, Who would've thought |
Yeah baffling issue. I'll close in favour of the other issue. |
Fixed in 8.4.0 and also in Watchexec 1.21.1 |
I've noticed that currently cargo-watch doesn't support Salvo web framework because when I use it with Salvo it doesnt work at all
A debug log
As I have said below, the terminal simply freezes up
Command I'm running
What I'm expecting to happen
I'm expecting cargo watch will do a normal hot reload
What's happening instead?
The terminal froze and every time I make a change it does nothing and stays frozen.
OS
macOS Monterrey 12.6.3
Rust: 1.67.0
How you installed Cargo Watch.
The text was updated successfully, but these errors were encountered: