attach_to_process warns about a short deny-list of known-bad adapterConfig keys, but any key outside that list is accepted in total silence. The most likely agent mistake — a typo of a supported key — therefore produces no feedback at all.
Repro
Deny-listed key → warns correctly (this is #450 working as designed):
Typo of the correct key → completely silent:
pathMapping vs pathMappings. One character. The agent now believes path mapping is configured; it isn't. In a real remote-attach (container debuggee, host checkout) the consequence is breakpoints that never bind, with the one lever that would have fixed it appearing — from the response — to have been accepted.
Same silence for an obviously-unknown key (bogusAttachKey: 1): accepted, unmentioned.
Why the current design can't catch this
The check is a deny-list of enumerated ptvsd-era keys. By construction it only ever catches keys someone already thought to write down. Typos, stale keys from other debuggers, and keys borrowed from a different adapter's docs all sail through.
This is the same class of defect #450 was filed to remove — "unknown attach keys must either work or warn" — just reached through a different door. A typo'd key does neither observably: it doesn't work, and it doesn't warn.
Suggested fix
Invert it: each adapter declares the adapterConfig keys it understands, and anything outside that set gets named in the existing warning field. That turns the check from "keys we remembered to ban" into "keys this adapter actually consumes", which catches typos for free.
Two refinements worth considering:
- Did-you-mean. With a known-good set in hand,
pathMapping → pathMappings is a trivial edit-distance suggestion, and it is exactly the moment an agent can act on it.
- Keep pass-through, just say so. If forwarding unknown keys to the adapter is deliberate (some adapters accept extras the wrapper doesn't model), that's fine — but the response should still list what was forwarded-unrecognised, so silence never means "understood".
The warning plumbing already exists and is already surfaced top-level on the response; this is a change to what populates it, not new machinery.
Agent-ergonomics impact: this is a silent-wrong-state defect. The agent's next N steps are built on a false belief about the session's configuration, and nothing in any response contradicts it.
Found during a full /testdebugger sweep (9 servers × 3 backends).
attach_to_processwarns about a short deny-list of known-badadapterConfigkeys, but any key outside that list is accepted in total silence. The most likely agent mistake — a typo of a supported key — therefore produces no feedback at all.Repro
Deny-listed key → warns correctly (this is #450 working as designed):
attach_to_process { port: 5679, adapterConfig: { localRoot: "/nope", … } } → { "success": true, "warning": "adapterConfig key(s) not supported by the python attach request were ignored: localRoot" }Typo of the correct key → completely silent:
attach_to_process { port: 5691, adapterConfig: { pathMapping: [ { localRoot: "…/examples/python", remoteRoot: "…/examples/python" } ] } } → { "success": true, "state": "paused" } // no warning field at allpathMappingvspathMappings. One character. The agent now believes path mapping is configured; it isn't. In a real remote-attach (container debuggee, host checkout) the consequence is breakpoints that never bind, with the one lever that would have fixed it appearing — from the response — to have been accepted.Same silence for an obviously-unknown key (
bogusAttachKey: 1): accepted, unmentioned.Why the current design can't catch this
The check is a deny-list of enumerated ptvsd-era keys. By construction it only ever catches keys someone already thought to write down. Typos, stale keys from other debuggers, and keys borrowed from a different adapter's docs all sail through.
This is the same class of defect #450 was filed to remove — "unknown attach keys must either work or warn" — just reached through a different door. A typo'd key does neither observably: it doesn't work, and it doesn't warn.
Suggested fix
Invert it: each adapter declares the
adapterConfigkeys it understands, and anything outside that set gets named in the existingwarningfield. That turns the check from "keys we remembered to ban" into "keys this adapter actually consumes", which catches typos for free.Two refinements worth considering:
pathMapping→pathMappingsis a trivial edit-distance suggestion, and it is exactly the moment an agent can act on it.The
warningplumbing already exists and is already surfaced top-level on the response; this is a change to what populates it, not new machinery.Agent-ergonomics impact: this is a silent-wrong-state defect. The agent's next N steps are built on a false belief about the session's configuration, and nothing in any response contradicts it.
Found during a full
/testdebuggersweep (9 servers × 3 backends).