Thanks for picking this up. Please check the feedback:

1. err.status is left undefined (correctness bug)

AxiosError's constructor normalises status from response:

if (response) {
  this.response = response;
  this.status = response.status;
}
(lib/core/AxiosError.js:49-52)

Both patched paths construct the error without response, then assign err.response = response afterwards. That bypasses the normalisation, so err.status stays undefined even though err.response.status is populated. AxiosError.toJSON() serialises the status directly, so logged/serialised errors will be inconsistent.

The convention already used elsewhere in this same file (see line 930) is to pass the response as the 5th argument:

responseStream.on('aborted', function handlerStreamAborted() {
  if (rejected) return;
  const err = new AxiosError(
    'stream has been aborted',
    AxiosError.ERR_BAD_RESPONSE,
    config,
    lastRequest,
    response
  );
  responseStream.destroy(err);
  reject(err);
});

responseStream.on('error', function handleStreamError(err) {
  if (req.destroyed) return;
  reject(AxiosError.from(err, null, config, lastRequest, response));
});

This removes the post-hoc assignment, sets status correctly, and drops the now-unnecessary if (response) guard (which is unreachable anyway, response is const-declared at line 839 in the same closure, before the listeners are attached).

2. Please add a regression test

This closes a long-standing issue (#6935), and there are no tests. At a minimum, one test per path:

• aborted: server writes headers, then res.destroy() mid-body → assert err.response.status, err.response.headers, and err.status.
• error: same setup with an emitted stream error → same assertions.

Asserting err.status in particular would have caught issue #1.

3. Scope clarification (optional, for the PR description)

This fix only applies to buffered responses. When responseType: 'stream', the adapter takes the early branch at line 847, and these listeners are never attached. Worth calling out so users with streamed responses don't expect the same behaviour. Also worth noting that err.response.data will be undefined on the aborted path since data is only assigned in the 'end' handler; only metadata (status/headers) survives, which matches the stated intent.

Once 1 and 2 are addressed, I think this is good to go. Patch-level change, no breaking concerns.

Thanks, addressed in 47d5c57.

Changes made:

• Passed response into AxiosError / AxiosError.from(...) directly for both buffered response stream aborted and error paths, so err.status is normalized correctly.
• Added regression coverage for both paths asserting err.response.status, err.response.headers, and err.status.

Validated locally:

• npm run test:vitest:unit -- tests/unit/adapters/http.test.js
• npx eslint lib/adapters/http.js
• git diff --check

Scope note: this remains limited to buffered responses; responseType: 'stream' still takes the early stream branch. On the aborted path, only response metadata is available, so err.response.data remains unset.