EAI_AGAIN Error Not Thrown on getaddrinfo Failure

[paucabuti]

Bug Description

In undici versions @7.1.0, and @7.0.0 the EAI_AGAIN error is no longer thrown when the getaddrinfo syscall fails. Instead, the request returns an object with { opaque: null }, which is unexpected behavior.
Additionally, this issue might be related to fix: response error interceptor #3930.

Reproducible By

1. Attempt to make a request to a hostname that triggers a getaddrinfo failure.
2. Observe that instead of throwing an EAI_AGAIN error, the response contains { opaque: null }.

[ruizmarc]

Hi,

We are also facing this problem and it's quite annoying as it is now harder to find out that one of services it is down it is not ready yet.

Is a fix coming soon? If not, is there any workaround?

Thanks in advance!

[mcollina]

Thanks for reporting!

Can you provide steps to reproduce? We often need a reproducible example, e.g. some code that allows someone else to recreate your problem by just copying and pasting it. If it involves more than a couple of different file, create a new repository on GitHub and add a link to that.

[ruizmarc]

Hi,

Here you have an example, you only need to do a simple request with the errors interceptor:

import { request, getGlobalDispatcher, interceptors } from 'undici';
 
await request('http://users:3000/users', {
  method: 'GET',
  dispatcher: getGlobalDispatcher().compose(interceptors.responseError()),
});

In my case I found the problem using docker, but it happens even without docker with a simple request. You can execute the example in this stackblitz: https://stackblitz.com/edit/node-fmjmkavv?file=index.js

In my use case, one microservice must request another one in the same docker network, but the one receiving the request is still not up.

Prior to version 7 we were receiving EAI_AGAIN if the microservice was not up with throwError, but now, with Undici 7, we just receive and empty response without any error even if there is nobody to reply.

[paucabuti]

I found another issue related to interceptors while investigating the missing EAI_AGAIN error.

Using the dns interceptor in combination with the responseError interceptor causes inconsistent behavior depending on their order:

• dns before responseError: The EAI_AGAIN error is correctly thrown, resolving the original issue.
• responseError before dns: Crashes with TypeError: handler.onError is not a function.

Here’s a reproducible example:

const { request, interceptors, getGlobalDispatcher } = require('undici');

(async () => {
  try {
    const response = await request('http://users:1000/',
      {
        dispatcher: getGlobalDispatcher().compose([interceptors.dns(), interceptors.responseError()])
      });
    console.log(response);
  } catch (error) {
    console.error('Caught error:', error);
  }
})();

[metcoder95]

The order of the interceptors matter, that's why you get one or the other depending on that.
I couldn't reproduce the initial error, as the response-error successfully throw on every network condition as expected.

For the combination of interceptors problems, I found the problem and the fix is on its way.

[ruizmarc]

Hi,

I don't know if by first error you are referring to the one I mentioned. Here you have a screenshot from the stackblitz showing the problem:

As you can see in the image, executing the code with the response error interceptor is not throwing any error

However, it works without the interceptor:

So the problem seems to be related with the response error interceptor that is not throwing the error in some cases.

Here the link to the stackblitz just in case it might help: https://stackblitz.com/edit/node-fmjmkavv?file=index.js

[metcoder95]

I don't know if by first error you are referring to the one I mentioned. Here you have a screenshot from the stackblitz showing the problem:

Yeah. was referring to this one. When attempting I was able to fully see the error being thrown (I tried with latest in main)