Problem
Found while tracing #242: the js-debug reverse startDebugging handler (packages/shared/src/interfaces/adapter-policy-js.ts:665-690) adds the __pendingTargetId to context.adoptedTargets up front and never removes it when adoption fails. ChildSessionManager.createChildSession's catch block resets adoptionInProgress and deletes its own adopted-target record, but the policy-level dedupe set keeps the id — so if js-debug re-sends startDebugging for the same pending target, the handler returns {handled: true} without creating a child. Adoption can never be retried for that target; the session silently has no debuggable child.
Suggested fix
Remove the id from adoptedTargets on the failure path (the createChildSession rejection is already observable at the dispatch site in minimal-dap.ts:289-311, where it is currently caught and only logged), or move the dedupe to consult ChildSessionManager's own adoption state, which is correctly rolled back on failure.
Problem
Found while tracing #242: the js-debug reverse
startDebugginghandler (packages/shared/src/interfaces/adapter-policy-js.ts:665-690) adds the__pendingTargetIdtocontext.adoptedTargetsup front and never removes it when adoption fails.ChildSessionManager.createChildSession's catch block resetsadoptionInProgressand deletes its own adopted-target record, but the policy-level dedupe set keeps the id — so if js-debug re-sendsstartDebuggingfor the same pending target, the handler returns{handled: true}without creating a child. Adoption can never be retried for that target; the session silently has no debuggable child.Suggested fix
Remove the id from
adoptedTargetson the failure path (thecreateChildSessionrejection is already observable at the dispatch site inminimal-dap.ts:289-311, where it is currently caught and only logged), or move the dedupe to consultChildSessionManager's own adoption state, which is correctly rolled back on failure.