Let a tool deliver a final result on caller abort

[minjikim89]

Per §3.1 cancel a pending tool execution, aborting the signal passed to executeTool() removes the pending execution and rejects the caller's promise with the abort reason; the tool's own resolution is discarded.

Verified in Chrome 152: the caller gets AbortError, and the { applied, remaining } payload the tool had built is lost.

Why it matters

For a long-running tool that applies changes incrementally (a batch edit landing item by item), the caller cannot learn what was applied before the abort. Partial progress is structurally unreportable on the caller's abort path, even though the tool knows exactly what it did.

This is not hypothetical for us. A sweep across a document is stoppable mid-run by design, and the agent has to be able to say what landed, or the person is left to diff the document by eye.

What we had to do instead

A page-owned AbortController combined with the caller's via AbortSignal.any(), so the tool resolves normally with a CANCELLED payload carrying applied / remaining / stoppedBy. It works, and it also lets us tell a caller abort apart from the person pressing stop on the page.

But it means the person's stop button and the caller's abort travel different paths for no reason the spec requires, and a site that does not build the second path silently loses the report.

Proposal

Allow execute to observe signal.aborted, finish promptly, and have that settled value delivered to the caller. Two shapes that would both work:

• reject with an AbortError whose cause carries the tool's result, or
• resolve if the tool settles within the same task as the abort.

Either keeps cancellation semantics, since the caller still learns it was aborted, while making partial progress reportable.

Notes from the build: https://github.com/minjikim89/redline/blob/main/docs/findings.md · live: https://minjikim89.github.io/redline/