Is "aborted" deprecated?

[fleming79]

In the documents about request/reply it mentions that 'abort' is deprecated and that status should be one of 'ok' or 'error'.

Further down in execution results it says

 # One of: 'ok' OR 'error' OR 'aborted'

Is 'aborted' permitted or deprecated?

[krassowski]

I think this need to be clarified:

• should we use abort or aborted for execute_reply
• aborted is the way that interruption result is communicated on cells nowadays, was it deprecated with discussion around how to signal to the cells that follow an interrupted cell?

[krassowski]

Related:

• deprecate status='abort' #200
• KeyboardInterrupt is not abort ipython/ipykernel#190
• Add basic interrupt functionality jupyterlite/jupyterlite#1683

I do not see a discussion on distinction of abort vs aborted. CC @minrk in case if you have suggestions (I am coming here from the jupyterlite PR linked above)

[minrk]

Thanks for finding and linking things I'd long forgotten!

I do not see a discussion on distinction of abort vs aborted

I think the distinction is only typos. I don't believe there are two separate statuses, only aborted as implemented by ipykernel and mistyped as 'abort' in the doc. If folks think 'aborted' is useful, we can revert the deprecation and clarify the docs to match what ipykernel does for stop_on_error. I think it is also okay to use status=error for these cases, as discussed in the original deprecation.

Is 'aborted' permitted or deprecated?

To answer the original question, yes and yes, since 'deprecated' means still supported, but discouraged. status=aborted is deprecated in the spec, though some kernels can still send it (e.g. ipykernel still does for cancelled executions, as @krassowski points out). Deprecated means it is still valid and can still happen, so for full functionality, a client can either support deprecated messages or ignore them, but kernels are encouraged to not produce them, with the documented suggestion of using status=error instead.

So for the purposes of jupyterlite supporting stop_on_error, following the docs suggests using status=error, or you can match ipykernel's continued use of the deprecated status=aborted. Both should be fine, but I'd be inclined to go with status=error as the deprecation message suggests.

[fleming79]

Thank you both very much for the clarification.

After a few days I'd decided it was a typo and replaced status='aborted' with status='error' in the kernel I'm working on.

Personally, I think it should remain deprecated and eventually phased out. The issue I see with 'aborted' is that it becomes necessary for the kernel to decide what should be marked as 'aborted' vs 'error' (unless it is explicitly defined in the spec).

[minrk]

It will never be wrong to use status=error, whether we undeprecate aborted or not, so that makes sense to me.

[krassowski]

The (tiny) inconvenience with status=error for interrupt use case is that it requires ename, evalue and traceback whereas abort (/aborted) does not.

[minrk]

Yeah. They are required to be populated, though they can be the string "aborted" or empty for the traceback. We should probably give a complete example.