Execution should stop after first error

[damiendr]

I believe the notebook or kernel should stop executing cells after the first error. At least this is how the Python version behaves.

On my system, IJulia 1.1.7 executes all queued cells no matter what, leading to cascades of errors & unexpected effects when an error occurs early in the queue.

[stevengj]

Do you mean when you execute Run All or similar in a notebook?

I just checked, and you are right: Run All with the IPython kernel stops after the first error, but Run All with the IJulia kernel continues executing subsequent cells.

@minrk, what are we doing wrong? I verified that when an error occurs we send back an execute_reply message with status: "error" and the traceback etc., but the notebook front-end keeps sending additional cells to execute.

[minrk]

Run All does not wait for replies before sending new requests. Run All sends all requests immediately, which get queued in zmq. It's up to the Kernel to flush the queue of pending requests on abort, if it chooses to do so.

[stevengj]

So you just send error replies for all the messages in the queue?

Or by "flush the queue" do you mean discard the execute_request messages? But according to the ZMQ FAQ "There is no explicit command for flushing a specific message or all messages from the message queue" short of closing the socket.

[stevengj]

If you could point out the relevant code in the IPython kernel that would be helpful.

[minrk]

Sure thing:

• abort if stop_on_error
• implementation of abort

[JamesWrigley]

I can think of two ways to implement this:

1. Record the timestamp when a cell fails and ignore all future messages with a date before that timestamp. The advantage is that we could preserve the existing architecture of one task for the shell socket. Unfortunately it requires parsing timestamps and the Dates stdlib doesn't handle timezones so we'd need to use TimeZones.jl, and I'm slightly unwilling to do that since TimeZones is a rather heavy dependency.
2. Separate the receiving of execute_request messages from their handling so that the task executing the requests can cancel whatever is currently in the queue. This isn't that different from the current architecture, but the problem is that the execute_request() handler needs to send messages on the shell socket and that could lead to a deadlock with the socket-receiver task. Fixing that is basically Make message receive and handling async #1140 (CC @halleysfifthinc).

I would propose we implement aborting by 2. since we want to do that anyway.

[halleysfifthinc]

Agreed, 2 would be easy to incorporate into #1140 by dumping all "in-flight"/received execute_request messages after an error.