fix: use err.name check for AbortError instead of instanceof Error#1867
fix: use err.name check for AbortError instead of instanceof Error#1867tsushanth wants to merge 1 commit into
Conversation
DOMException (thrown by AbortSignal/AbortController) is not instanceof
Error in Node and Bun, so guards of the form:
if (err instanceof Error && err.name === 'AbortError')
never match. The instanceof check is redundant for the name property
since any thrown value can carry it. Replace all six occurrences across
agents and plugins with:
if ((err as { name?: string })?.name === 'AbortError')
This silences the spurious error-level log noise on normal turn and
session teardown that triggered livekit#1712.
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
|
|
||
| // Handle timeout errors | ||
| if (error instanceof Error && error.name === 'AbortError') { | ||
| if ((error as { name?: string })?.name === 'AbortError') { |
There was a problem hiding this comment.
🚩 Incomplete transformation — several locations still use the old pattern
The PR changes 8 locations but leaves several others untouched that have the same instanceof Error && ... === 'AbortError' pattern:
agents/src/inference/tts.ts:883and:895agents/src/stream/deferred_stream.ts:34plugins/elevenlabs/src/tts.ts:920plugins/inworld/src/tts.ts:455
These remaining locations could hit the same DOMException-not-instanceof-Error issue. The deferred_stream.ts:34 case has a valid reason to keep instanceof Error since it accesses e.message afterward, but the others (inference/tts.ts, elevenlabs/tts.ts:920, inworld/tts.ts) appear to just return/ignore the error and would benefit from the same fix.
Was this helpful? React with 👍 or 👎 to provide feedback.
1 participant
Fixes #1712
DOMException, which is whatAbortSignal/AbortControllerthrows, is notinstanceof Errorin Node.js or Bun. As a result, guards written as:never match a real abort. The
instanceof Errorcondition is already false forDOMException, so the abort falls through to the error-level logger — producing the spuriousDOMExceptionconstant table in logs on every normal turn teardown.The
.nameproperty is not exclusive toErrorsubclasses; any thrown value can carry it. Droppinginstanceof Errorand using an optional-chaining cast:matches both
Errorsubclasses andDOMExceptionuniformly across runtimes, which is the same approach the Web Platform (and Node's ownAbortSignaldocs) recommends.Six occurrences fixed across the agents package and the Google, ElevenLabs, and OpenAI plugins.