Questions about the debug message spec

[SpencerPark]

I'm looking into implementing the kernel side of the debugging protocol and had some questions regarding the messaging spec. Specifically regarding the request/reply sequencing and expectations regarding the reply order.

The debug_request/reply spec mentions that:

The content dicts of the debug_request and debug_reply messages respectively follow the specification of the Request and Response messages from the Debug Adapter Protocol (DAP) as of version 1.39 or later.

but none of the extension message specs include seq or request_seq in their content dicts. Is this part of the DAP ignored in favor of jupyter's existing message parent mechanism or just omitted from the docs for brevity? If so, is that specific to the extensions only or do all DAP replies use the parent header instead of request_seq?

Related to that, is there the expectation that while a debug_request is being handled, all other incoming (from kernel's perspective) control messages are queued until the debug_reply is sent? Or should control requests be handled concurrently unlike shell? For example if a slow debug_request is running and an interrupt_request comes in, does it wait for the debug_request to complete?

[SpencerPark]

Follow up, it seems like at least for jupyterlab, a kernel is expected to declare metadata.debugger = true in their kernelspec and the debugger field in the kernel info reply is unused. Only if that is set, then implementation support is queried by sending a debug_request.debugInfo (always with seq=0) request that should return a successful reply.

Would appreciate some confirmation (or a correction) if this is the expected protocol and can look at adding to the docs :)

EDIT: related #737