Does undici take care of consuming the response body if throwOnError: true?

[schaable]

Hi everyone,

I have a question regarding error handling and garbage collection in Undici. Here’s a example of a request I’m making:

try {
  const response = await request("http://example.com", {
    method: "POST",
    body: JSON.stringify({ /* some body */ }),
    throwOnError: true,
  });
 } catch (error) {
  // Handle error
}

If the request fails with a 4xx or 5xx status code, the function throws a ResponseStatusCodeError. According to the docs, I should always consume() or destroy() the body. However, the body in ResponseStatusCodeError is of type null | Record<string, any> | string and not BodyReadable & BodyMixin (which is its type in ResponseData) so I can't call these methods.

Is this correct? Can I assume that, in this scenario, Undici will handle garbage collection correctly?

[metcoder95]

👋

Yes, if the request fails with a range grater or equal than 400, Undici will read the body and attach it to the Error's properties.

It is worth mentioning that this will change in the future major. If you want to preserve this behaviour, you'll need to use an interceptor instead.

[paymog]

What if throwOnError is not set (or set to false which is the default)? Will we have to manually destroy the response body in a finally clause like so

let responseBody: any;

try {
  const { statusCode, body } = await finalNode.pool.request(/* ... */);
  responseBody = body;

  latestBody = await body.text();

  // ... rest of your logic
} catch (e) {
  // ... error handling
} finally {
  if (responseBody && !responseBody.destroyed) {
    responseBody.destroy();
  }
}

[metcoder95]

Yeah, exactly; but I don't think you'll face a situation like that, as if you receive an error while reading the body from undici, it mostly means the body is corrupted but already read.

Use response.body.dump in combination with response.body.destroy if you want to dump the after an error