Question about AbortSignal usage after successful request completion #1580

Background

I've been debugging an issue where our monitoring tools were flagging successful RPC calls as "aborted". After investigating, I found that Connect-ES calls abort() in the done() handler of runUnaryCall
(packages/connect/src/protocol/run-call.ts:189), even after the request completes successfully.

This made me curious about why Connect-ES doesn't rely on the natural cleanup that happens when fetch completes.

What I Found

It appears that Connect-ES uses controller.abort() as a way to trigger cleanup of event listeners created by createLinkedAbortController. While this works technically, I'm wondering if this might be
causing some confusion.

My Understanding

From my perspective, it seems like:

• When a fetch request completes successfully, it should be marked as "finished"
• The abort() signal typically indicates cancellation or failure
• Using abort() for cleanup after success might be sending mixed signals (pun intended 😅)

Questions

1. Is there a specific reason for using abort() for cleanup rather than a dedicated cleanup mechanism?
2. Could this pattern potentially cause issues with monitoring tools or debugging?
3. Would the team be open to exploring alternative cleanup approaches?

Impact

This pattern is causing our monitoring tools to misreport successful requests as aborted, which makes it harder to track actual failed requests.

I'd love to understand the design decision better and see if there's a way to address the monitoring confusion. Thank you for your work on this great library!