Debugger does not conform to DAP specification
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 30/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- python
- Domain
- backend-api-design, devtools
Research direction
Start with ipykernel/debugger.py at _handle_init_sequence and compare its request handling with the DAP initialization sequence in the linked Microsoft documentation. Trace how attach, configuration requests, and configurationDone are currently ordered; done means the kernel can support the required parallel requests without completing attach before configuration responses are received.
Written by the indexing model from the issue text.
Description
Per Microsoft's documentation for the Debug Adapter Protocol, a DAP client should send the launch/attach request in parallel with the various configuration requests, such as setBreakpoints and setExceptionBreakpoints. Only once those configuration requests have received responses should the client send configurationDone, at which time the adapter will return a response to the original launch/attach request. This allows the adapter to fully configure itself before the client considers itself attached.
ipykernel does not currently conform to this specification. It includes a _handle_init_sequence method which manually sends the configurationDone request to the adapter rather than use the original one from the client. It does this in response to the original attach request, too, well before the client would have sent that message itself.
This is problematic because:
- This method assumes DAP to work synchronously, whereas by definition the initialization sequence is meant to be conducted in parallel
- The
configurationDonerequest may make it to the adapter before the actual configuration requests (setBreakpoints...). This may cause issues (which we have actually seen) where the DAP client receives a response toattachbefore the adapter is done configuring. This leads to breakpoints not being set in time and ultimately being missed.
The root of this problem is the synchronous handling of DAP requests by ipykernel; the kernel cannot send Request B until Request A receives a response, so this parallel nature of initialization is currently not possible to conform to.
The solution to this problem would be to change how ipykernel handles DAP requests. One solution would be to use a queue to which requests are pushed, similar to how responses are handled. We can implement a working solution and submit a PR, if the maintainers are okay with it.
- Dominant language
- Python
- Stars
- 734
- Forks
- 411
- Avg merge
- 1d 2h
- Merged PRs (30d)
- 9
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ipython/ipykernel
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
Difficulty 4/5 3-5 days Newbie friendliness 68/100
-
ipython/ipykernel#1550 · 1 comment · 1 reaction · 1 assignee ·
All issues in ipython/ipykernel
Similar issues
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
canonical/paas-charm#368 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
tech debt
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
StevenBlack/hosts#3256 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
qualcomm/qai-appbuilder#275 ·