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.

Sign up for GitHub

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

lsp server: fix response sending order #64

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

lsp server: fix response sending order #64

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
765df2e
lsp server: fix response sending order
umutdural Jan 29, 2025
21b0680
refactor: lsp-server response and timeout handling order
umutdural Feb 4, 2025
5ce6f54
vscode-ext: add loading animation, separate timeout from unknown, mov…
umutdural Feb 8, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 28 additions & 22 deletions src/servers/lsp.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -440,32 +440,38 @@ async fn handle_verify_request(
};

let result = verify(&[file_id]).await;
let res = match &result {
Ok(_) => Response::new_ok(id, Value::Null),
Err(err) => Response::new_err(id, 0, format!("{}", err)),
};

match result {
Ok(()) => {}
Err(VerifyError::Diagnostic(diagnostic)) => {
server.lock().unwrap().add_diagnostic(diagnostic)?;
}
Err(VerifyError::Interrupted) | Err(VerifyError::LimitError(_)) => {
// If the verification is interrupted or a limit is reached before the verification starts, no verification statuses are published yet.
// In this case, the client needs to be notified about the registered source units that are not checked yet (marked with VerifyResult::Todo).
// This acts as a fallback mechanism for this case.
server
.lock()
.unwrap()
.publish_verify_statuses()
.map_err(VerifyError::ServerError)?;
Ok(()) => {
let response = Message::Response(Response::new_ok(id, Value::Null));
sender
.send(response)
.map_err(|e| VerifyError::ServerError(e.into()))?;
}
Err(err) => Err(err)?,
}

sender
.send(Message::Response(res))
.map_err(|e| VerifyError::ServerError(e.into()))?;
Err(err) => {
let response = Response::new_err(id, 0, format!("{}", err));
match err {
VerifyError::Diagnostic(diagnostic) => {
server.lock().unwrap().add_diagnostic(diagnostic)?;
}
VerifyError::Interrupted | VerifyError::LimitError(_) => {
// If the verification is interrupted or a limit is reached before the verification starts, no verification statuses are published yet.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why handle that case here? Why don't we just immediately publish_verify_statuses() after registering them?

Also, isn't this case about publishing those that are now timeouts, not Todo anymore?

// In this case, the client needs to be notified about the registered source units that are not checked yet (marked with VerifyResult::Todo).
// This acts as a fallback mechanism for this case.
server
.lock()
.unwrap()
.publish_verify_statuses()
.map_err(VerifyError::ServerError)?;
}
_ => {}
}

sender
.send(Message::Response(response))
.map_err(|e| VerifyError::ServerError(e.into()))?;
}
}
Ok(())
}