Summary
When a live setBreakpoints re-send fails, the adapter's own answer reaches only the one set_breakpoint response that triggered it (warning: "Breakpoint state updated, but live sync failed: <adapter message>"); it is never stamped onto the breakpoint records, so list_breakpoints shows the breakpoints as merely verified: false with no message, and the launcher's post-launch resyncAll discards the answer altogether.
Measured while working #746/#749 on a python launch with noDebug: true (examples/python/pause_test.py): a live set_breakpoint answers with debugpy's own words — live sync failed: Server is not available — and the pre-launch breakpoint that resyncAll re-sent got the same answer, discarded. list_breakpoints then shows both breakpoints with no reason (#749 supplies the noDebug why beside them, but the adapter's answer itself is lost).
What would help
In BreakpointController.syncBreakpointsForFile (and syncFunctionBreakpoints), stamp the failure message onto each record the re-send covered (message, verified: false) the way the worker's breakpoints_synced echo does for a refused pre-launch set (#750), so the adapter's answer survives into list_breakpoints and the run-to-completion summary — "let the debugger speak for itself". resyncAll then needs no special handling.
Refs #746, #749, #750.
Summary
When a live
setBreakpointsre-send fails, the adapter's own answer reaches only the oneset_breakpointresponse that triggered it (warning: "Breakpoint state updated, but live sync failed: <adapter message>"); it is never stamped onto the breakpoint records, solist_breakpointsshows the breakpoints as merelyverified: falsewith nomessage, and the launcher's post-launchresyncAlldiscards the answer altogether.Measured while working #746/#749 on a python launch with
noDebug: true(examples/python/pause_test.py): a liveset_breakpointanswers with debugpy's own words —live sync failed: Server is not available— and the pre-launch breakpoint thatresyncAllre-sent got the same answer, discarded.list_breakpointsthen shows both breakpoints with no reason (#749 supplies the noDebug why beside them, but the adapter's answer itself is lost).What would help
In
BreakpointController.syncBreakpointsForFile(andsyncFunctionBreakpoints), stamp the failure message onto each record the re-send covered (message,verified: false) the way the worker'sbreakpoints_syncedecho does for a refused pre-launch set (#750), so the adapter's answer survives intolist_breakpointsand the run-to-completion summary — "let the debugger speak for itself".resyncAllthen needs no special handling.Refs #746, #749, #750.