Let a tool deliver a final result on caller abort #299

Activity

1. mysticalseeker24 commented on Sep 12, 2026

   

   mysticalseeker24

   on Sep 12, 2026

   More actions

   Measurements from a second implementation, Chrome 152, which I think make the case stronger than "partial progress is unreportable" — and one question about your workaround.

   execute has no signal to observe

   The proposal's first half is "allow execute to observe signal.aborted". In Chrome 152 there is nothing to observe, because execute is invoked with one argument:

   argc: 1
   inputType: "object"
   optionsType: "undefined"
   hasSignal: false
   

   Registered via a bare registerTool from a probe page, not through any framework. executeTool(tool, args, { signal }) is accepted on the caller side and does cancel the caller — so the gap is entirely on the execute side. A tool cannot observe the abort, promptly or otherwise.

   That is worth separating from the resolution-delivery question, because shape (a) and shape (b) both presume the tool can notice. Neither is implementable today regardless of what the spec says about the settled value.

   The tool does not stop — it finishes, and the writes land

   This is the part I did not expect. A tool that applies items in a loop, with the caller aborting partway:

   caller:  AbortError "stopped by the probe"   (hasCause: false)
   tool:    ran all 5 iterations to completion
   page:    <body data-applied="5">
   

   The side effect is written to the DOM inside the loop, so data-applied="5" is a fact about the page rather than a variable inside the closure. Every item landed. The caller was told the operation was aborted.

   So for a write tool the current behaviour is not "the caller cannot learn what was applied before the abort". It is the caller is told nothing was completed while everything was. Same shape as #300 — an action reported as not-having-happened after it happened — reached by a different route. An agent that aborts a batch edit and then retries it has now applied it twice.

   No cause to hang a result on

   Shape (a) proposes rejecting with an AbortError whose cause carries the tool's result. For reference, today's rejection has cause: undefined, so that shape needs a vehicle added rather than populated.

   Shape (b) — resolve if the tool settles within the same task as the abort — seems the more robust of the two, since it does not depend on callers reading a non-standard place for a payload. Though it only helps a tool that can stop promptly, which loops back to the missing signal.

   A question about your workaround

   You describe combining a page-owned AbortController with the caller's via AbortSignal.any(). Given the measurement above I cannot see how a page reaches the caller's signal — is execute receiving an options argument in your build, or are you obtaining it another way? If there is a route to it, that is worth having in the issue, because the page-side half of your mitigation is otherwise unavailable to anyone on 152 and the "site that does not build the second path" is then every site.

   Probe and notes: https://github.com/mysticalseeker24/parity-webmcp
2. minjikim89 commented on Sep 12, 2026

   

   minjikim89

   on Sep 12, 2026

   Author

   More actions

   Hi @mysticalseeker24 — you are right, and the honest answer to your question is that we do not reach the caller's signal either. Thanks for probing it rather than taking the issue text at its word.

   The line is a conditional:

   const signal = opts?.signal ? AbortSignal.any([opts.signal, page]) : page;

   On Chrome 152 opts is undefined, so it falls through to the page signal alone and the AbortSignal.any() branch never runs. The issue text describes the intended shape rather than what the tested browser exercises, which is the same defect you found in my #300 workaround paragraph. I will correct it.

   Two consequences I had not stated, which your measurement makes visible:

   1. stoppedBy: 'agent' is unreachable on 152. The payload distinguishes a person's stop from a caller's abort, but only the person's branch can be produced there. The distinction is real in the code and dead in the browser.

   2. The sweep runs to completion on caller abort in our build too. Nothing in the loop observes the caller, so the writes land exactly as your probe shows while the caller receives AbortError. I had described the loss as the report not arriving. Your framing is the accurate one: the caller is told nothing completed while everything did, and a batch edit retried after an abort applies twice.

   So your separation is right, and the missing execute signal should come first. Shapes (a) and (b) both presume a tool that can notice the abort, and today none can, so neither is implementable regardless of what the spec says about the settled value. That deserves to be its own ask rather than an assumption inside this one.

   On (b) being the more robust shape: agreed, with the caveat you name. It only helps a tool that can stop promptly, and "promptly" is not expressible without the signal.

   I will edit the issue to separate the two asks and to correct the workaround description.
3. minjikim89 commented on Sep 12, 2026

   

   minjikim89

   on Sep 12, 2026

   Author

   More actions

   A correction from me, and thanks again to @mysticalseeker24 for the probe and to @mlmrx for catching what I made of it on #308. The "a tool must be able to observe the abort" ask I added above is not a spec gap. The draft passes ToolExecuteCallbackOptions.signal to execute, and Chromium threads it in CL 8025300, first shipped in 153. Chrome 152 branched before that landed, which is why the probe sees one argument. I have verified on Chrome 153: execute receives two arguments, the signal fires, and a loop that checks it stops partway (3 of 5 items in my run). What the caller receives is still a bare AbortError with no cause, so the settlement question is unchanged. I have taken the extra ask out of the body.

   What remains is the original question, and I think it is the interesting one: when the caller's abort and a later fulfilment race, which settlement wins.
4. mysticalseeker24 commented on Sep 12, 2026

   

   mysticalseeker24

   on Sep 12, 2026

   More actions

   Taking the correction — @mlmrx is right and my framing was wrong. I described a browser and called it a precondition on the spec, which is exactly the mistake I had just flagged in someone else's paragraph. Thanks for catching it rather than building on it.

   I can add an independent confirmation and one observation that survives the fix.

   Confirmed on Chromium 153, from a different browser

   Edge 153.0.4234.32, same probe as before:

   execute:  argc 2, optionsKeys ["signal"], a real AbortSignal
   tool:     observed the abort at item 2 and stopped
   page:     <body data-applied="3">          (3 of 5, not 5 of 5)
   caller:   AbortError "stopped by the probe", cause: undefined
   

   Same 3-of-5 you saw. The write is genuinely cancelled, so the "runs to completion" behaviour is 152-only and I have scoped it that way in our notes.

   The caller's abort reason does not reach the tool

   This one I had not looked for, and it seems relevant to the settlement question you say is what remains.

   Aborting with an explicit reason:

   callerAc.abort(new DOMException("stopped by the probe", "AbortError"));

   gives, on 153:

   caller's rejection .message	"stopped by the probe"
   tool's signal.reason.message	"signal is aborted without reason"
   tool's signal.reason === the caller's object	false

   So the tool is told that it was cancelled but never why. The caller's reason reaches the caller and stops there.

   That bites the same use case this issue is about. Your CANCELLED payload carries stoppedBy, and with the signal arriving you can now distinguish a person's stop from a caller's abort by which controller fired — but a tool still cannot record what the caller said when it aborted, so it cannot annotate the final value with the cause even once it is able to produce one. If the resolution here ends up being shape (a), a tool that could attach { applied, remaining, abortedBecause } seems strictly more useful than one that can only attach { applied, remaining }.

   Worth noting it may well be deliberate — the tool's signal is a distinct signal, not the caller's — in which case the question is whether the reason should be propagated onto it, rather than whether this is a bug.

   Probe: https://github.com/mysticalseeker24/parity-webmcp
5. markafoltz

   added

   enhancementNew feature or requestNew feature or request

   on Sep 23, 2026
6. domfarolino commented on Sep 25, 2026

   

   domfarolino

   on Sep 25, 2026

   Collaborator

   More actions

   Thanks for filing this! Now that we've clarified that the tool does receive the caller's AbortSignal, I don't think we need any additional API here.

   Once the caller aborts an invocation, I think the cleanest semantic is that its promise rejects and any eventual result from the tool is discarded. This matches all othe rusages of AbortSignal on the platform too, like fetch("...", {signal}). If it needs to expose the resulting state after cancellation, that seems better handled by the tool/application itself rather than by returning a result through an invocation the caller has already aborted.

   Given this, I really don't need we should deviate from existing AbortSignal semantics, so I'll close this for now.
7. domfarolino

   closed this as not plannedon Sep 25, 2026