UND_ERR_***_TIMEOUT explanation

[nicklaros]

Hi,

I have been looking for explanation on these error and when it is thrown, but still can not find it.

• UND_ERR_BODY_TIMEOUT
• UND_ERR_CONNECT_TIMEOUT
• UND_ERR_HEADERS_TIMEOUT
• UND_ERR_SOCKET_TIMEOUT

Can someone please point me on the link for this error documentation?

Thank you.

[sam-goodwin]

Any update on this. Running into these problems also.

[ronag]

I don't think it's documented. PR welcome.

[sam-goodwin]

I don't think it's documented. PR welcome.

I think this issue is pointing out that we don't know what these errors mean. We have educated guesses from the names but that's about it. There's very little to be found on google either.

I'd love to help but I doubt I would be able to document something I don't understand - that's probably the author's responsibility.

[mcollina]

They are self-explanatory to me (the explanation is in their name), there is not much more to it.

I would document them as:

UND_ERR_BODY_TIMEOUT is an error that is thrown if the body of an HTTP response is not received within the bodyTimeout.

Each one of them as an option in the docs to control the timeout. The timeout for connect is in https://undici.nodejs.org/#/docs/api/Client?id=parameter-connectoptions.

I can't find a reference to UND_ERR_SOCKET_TIMEOUT in our codebase, not sure where you found that.

[sam-goodwin]

They are self-explanatory to me (the explanation is in their name), there is not much more to it.

Sure, they kind of are. But I ran into this problem while using fetch on node 18 and had never heard of undici before. Googling led me here and i still don't know how to resolve my problem. I don't know why my "headers" are timing out nor how to increase the timeout. That link seems to rely on me using undici directly, but I'm using fetch.

I think the assumption of their meaning and resolution being obvious isn't quite fair.

[mcollina]

That link seems to rely on me using undici directly, but I'm using fetch.

This is probably the missing information that was not described in the issue and why I was a bit puzzled by it.

I think the assumption of their meaning and resolution being obvious isn't quite fair.

If you are an undici user, you should know where to look if one of the Undici API throws and error. If you are a native fetch() user, you likely aren't.

I can totally see the problem now, thanks for the missing context!

(It's still a pretty straightforward documentation fix).