-
Notifications
You must be signed in to change notification settings - Fork 15
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
Streamline handling of Shell replies #575
Conversation
crates/amalthea/src/socket/shell.rs
Outdated
@@ -145,7 +147,7 @@ impl Shell { | |||
self.handle_request(req, |h, r| self.handle_comm_info_request(h, r)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your change to remove handle_request()
from handle_comm_msg()
below implies we could also do it here with handle_comm_info_request()
, because it doesn't use the shell_handler
either?
But unlike handle_comm_msg()
, handle_comm_info_request()
does have a return value it needs to send back. So that makes things complicated.
9b48d46
to
34c58a7
Compare
34c58a7
to
611894b
Compare
crates/amalthea/src/kernel.rs
Outdated
let lsp_handler_clone = lsp_handler.clone(); | ||
let dap_handler_clone = dap_handler.clone(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While we are here - these don't need to be clones either!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wish the compiler would let us know.
comm_id: req.content.comm_id.clone(), | ||
}); | ||
self.iopub_tx.send(reply).unwrap(); | ||
log::warn!("Failed to open comm: {err:?}"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
warn or error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Warn otherwise this shows up in the test output.
So it's obvious which channel is used
Some clean ups following discussion in #547.
Shell handlers now return an
amalthea::Result
.New
amalthea::Error::ShellErrorReply
variant for error replies. When a handler returns one, it's forwarded to the client as a Shell reply.The
amalthea::Error::ShellErrorExecuteReply
variant is specifically for execution replies as they are the only ones that need an execution count.(This count is currently created by the R thread. We might want to move some of this handling to the Shell socket: it could create it, bump it when appropriate, etc. The Shell socket might also become in charge of sending Inputs and Results to IOPub to remove as many protocol details from Ark as possible).
Removed the
ExecuteResponse
enum as we now pass that information through anamalthea::Result
.New
Shell::send_execute_error()
method. Sends errors for execute requests with the execution count.Shell::handle_request()
is now in charge of sending replies from handlers. All errors, including internal (i.e. not the two variants discussed above) are forwarded to the frontend as replies.