start_debugging should carry location and note when it answers a stop; get_stack_trace as the other carrier of the stale-build note (#950 follow-up) #951

Activity

1. debugmcpdev

   added

   enhancementNew feature or requestNew feature or request

   on Oct 19, 2026
2. debugmcpdev

   added 3 commits that reference this issue on Oct 19, 2026

   feat(breakpoints): warn when a compiled language's source is newer th…

   ...

   1e85784

   fix(handlers): one openable-path rule for every stop carrier; drop th…

   ...

   e8a9937

   feat(launch): start_debugging answers a stop with where it is, and ge…

   ...

   e0bf696
3. debugmcpdev

   closed this as completedin #960on Oct 19, 2026
4. debugmcpdev commented on Oct 19, 2026

   

   debugmcpdev

   on Oct 19, 2026

   CollaboratorAuthor

   More actions

   Shipped in #960.

   Both proposals, as filed:

   1. start_debugging (and restart_debugging, which replays a launch) carries location, context, and threadId/note when it answers a stop, the way wait_for_stop does — one describeStopLocation read on the launch answer's PAUSED arm (an auto-continued entry stop never reaches it: the readiness wait's microtask re-read, wait_for_stop: block until a session's next stop or end instead of polling list_debug_sessions #849, sees the RUNNING the continue sets). location and threadId sit at the top level and in data; context and the full note at the top level. The launch message is unchanged.
   2. get_stack_trace appends the same stale-build sentence when the file of its top frame is newer than the compiled file the debugger binds it through — the top frame only, and not a <…> label, a relative spelling or an unresolvedSource frame. The same openable-path rule now gates the line read and the stale probe on every stop answer.

   Measured on the dev proxy (Windows, aged dotnet.dll, breakpoint in Program.cs):

   call	before	after
   start_debugging (paused at the breakpoint)	data.reason: "breakpoint", nothing else	top-level location (Program.cs:8), context, note naming the DLL and the source with both mtimes
   get_stack_trace	no note	the same note
   wait_for_stop (control)	the note	the note
   after dotnet build, relaunch	—	location + context, no note, on both
   Python stopOnEntry launch (control)	—	location (hello.py:1) + context, no note

   So the fast-program flow set_breakpoint → start_debugging → get_stack_trace → get_local_variables now sees the sentence twice where it saw it zero times.

   Also in the PR: the three identical hoist-plus-stale-check blocks in execution-tools.ts (step, wait_for_stop, pause_execution) became one helper, hoistStopLanding, which the two launch handlers call as well; the start_debugging and get_stack_trace tool descriptions name the new fields; the seven doc pages that said "(#951)" now name the carriers.

   CI-run proof with a real adapter: the #823 case in tests/integration/javascript-launch-config.test.ts asserts the launch answer's location.line and context at the line-9 breakpoint. The Java/.NET/C++/JavaScript e2e aging cases assert the launch carrier (.NET, JavaScript — the fixtures that are paused when the launch answers) and the get_stack_trace carrier (all four); those files run on no CI lane.

   Not done here, deliberately: lastStop on the launch answer (reason is there; wait_for_stop and get_stack_trace carry the record); the launch message wording; a note on get_local_variables/get_variables; an unresolvedSource flag on location itself (an absolute path behind a sourceReference is still probed — a probe of a file that exists here is a fair one).

   Side finding while measuring: #959 (a .NET launch without dapLaunchArgs.program passes the .cs to netcoredbg and fails with a bare 0x800700c1).