Skip to content

Excessive NodeError creation while using AbortSignal.timeout #4032

@slagiewka

Description

@slagiewka

Bug Description

I'm not sure if this is something that undici should handle or something that can be patched in node.

We're using a timeout signal in every request made by fetch. Since the service is working as an API gateway, we do this A LOT.

It seems like this check is running unnecessary: AbortSignal has [kMaxEventTargetListeners] set to 0.

So the getMaxListeners does not check considers the AbortSignal to be an EventTarget because the condition:

else if (emitterOrTarget?.[kMaxEventTargetListeners])

evaluates to 0.

Should this not be surrounded by try-catch like is in undici this would result in:

TypeError [ERR_INVALID_ARG_TYPE]: The "emitter" argument must be an instance of EventEmitter or EventTarget. Received an instance of AbortSignal

Reproducible By

This should be as simple as running

import {fetch} from 'undici';

await fetch('https://nodejs.org', {signal: AbortSignal.timeout(1_000));

Expected Behavior

Less time spent creating invisible, unimportant errors 🙂

Logs & Screenshots

The offending tree
Image

getMaxListeners
Image

Expensive NodeError
Image

Callsite
Image

Environment

Node v22.13.1 (running inside Alpine on Docker)
Using undici v7.

Additional context

I see that there was this issue about the error being visible: nodejs/node#46823
Now it's just silent, but expensive.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions