Add integration test for R errors #547
Open
+114
−37
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Branched from #542
I was confused for a while trying to make tests for execution errors because of some puzzling ambiguities:
In the Jupyter protocol all replies have nominally one type (
foo_reply
withfoo
corresponding to the request name, e.g.foo_request
), but they each have two different structural types. When thestatus
field is "error", all fields are omitted and instead the exception fields (ename
,evalue
,stacktrace
, represented by the Rust typeException
) are included. The contents of the error variants of these messages are represented by the Rust typeErrorReply
, which currently has"error"
asmessage_type()
.As special case, the error variant of
"execute_reply"
messages must also preserve theexecution_count
field. This is represented by the Rust typeExecuteReplyException
.Ark handles this downstream and for this reason (I think) we don't use
send_error()
in Amalthea's Shell socket, we usesend_reply()
in both cases, which is also confusing:ark/crates/amalthea/src/socket/shell.rs
Line 235 in 1c7a78f
Execution errors are also signaled on IOPub with messages of type
"error"
. These are represented by the Rust typeExecuteError
.Things changed in this PR:
I was confused by
ErrorReply
having the samemessage_type()
(ark/crates/amalthea/src/wire/error_reply.rs
Line 31 in eef44b6
ExecuteError
messages (ark/crates/amalthea/src/wire/execute_error.rs
Line 24 in eef44b6
error_reply()
, seeark/crates/amalthea/src/wire/jupyter_message.rs
Line 347 in 1c7a78f
message_type()
method for type reasons involving expected traits. So I set the message type to"*error payload*"
to better reflect it's only a placeholder.We now take precautions in the
try_from()
method that deserialises Jupyter messages to disambiguate between the regular and error variants of"execute_reply"
.The error situation is now better documented so it's not as confusing the next time we have to deal with Jupyter errors.