controller.errorWith ends up in the response path if the error is not Error instance

[mikicho]

interceptors expects the error to be from type Error in handleRequest, which is not required by Node.

const http = require('http')
const { ClientRequestInterceptor } = require('@mswjs/interceptors/ClientRequest')

const interceptor = new ClientRequestInterceptor()

interceptor.on('request', async function rootListener({ controller }) {
  controller.errorWith({ message: 'custom error', code: 'test' })
})
// interceptor.apply()

const req = http.request('http://example.com')

req.on('response', () => {
  console.log('response');
})
req.on('error', e => {
  console.log('error', e);
})

req.end()

If the interceptor is applied, the program prints response and throws:

/.../nock/node_modules/@mswjs/interceptors/lib/node/chunk-WTJL7BRV.js:234
if (!Reflect.has(headers, kRawHeaders)) {
               ^

TypeError: Reflect.has called on non-object
    at Reflect.has (<anonymous>)
    at getRawFetchHeaders (/home/michael/projects/js/nock/node_modules/@mswjs/interceptors/lib/node/chunk-WTJL7BRV.js:234:16)
    at MockHttpSocket.respondWith (/home/michael/projects/js/nock/node_modules/@mswjs/interceptors/lib/node/chunk-WTJL7BRV.js:488:32)
    at Object.onResponse (/home/michael/projects/js/nock/node_modules/@mswjs/interceptors/lib/node/chunk-WTJL7BRV.js:901:18)
    at handleResponse (/home/michael/projects/js/nock/node_modules/@mswjs/interceptors/lib/node/chunk-TQD7SQGP.js:100:21)
    at handleRequest (/home/michael/projects/js/nock/node_modules/@mswjs/interceptors/lib/node/chunk-TQD7SQGP.js:186:12)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async _ClientRequestInterceptor.onRequest (/home/michael/projects/js/nock/node_modules/@mswjs/interceptors/lib/node/chunk-WTJL7BRV.js:895:32)

Node.js v20.17.0

For real requests, it is called the error callback.

WDYT?

[marikaner]

I have the same issue currently when using @mswjs/interceptors through nock. I am currently unable to produce a reproducible example, so it is very difficult to investigate this.
Does anyone have an idea for a workaround until this is fixed? @mikicho maybe?

[mikicho]

@marikaner In order to keep this issue clean, I opened an issue in nock to track this and discuss about workaround (nock/nock#2789)

[kettanaito]

I think it should be safe to allow arbitrary error reasons. .destroy() isn't strict about this, as you've mentioned, and some other clients don't support custom error reasons at all.

The only thing, I'd be careful with the handleRequest as it tackles a bunch of scenarios and some of them are not that apparent. But all are covered with tests so any change will be verified.

I'd probably suggest to refactor handleRequest to have two internal callbacks: onResolve and onReject that are called whenever something is returned via .respondWith() or something throws during the request resolution (no matter if via throw or .errorWith()). Basically, to streamline the request handling to two paths:

• Something resolved this request to X;
• Something rejected this request with Y.

The current handleResponse and handleResponseError are too vague. Besides, there are situations when thrown errors are responses and get handled as response, which is confusing to read:

interceptors/src/utils/handleRequest.ts

Lines 74 to 77 in 472bcbe

	// Handle thrown responses.
	if (error instanceof Response) {
	return await handleResponse(error)
	}

We can likely keep the existing handleResponse/handleResponseError, maybe rename them, and use them within the newly added onResolve and onReject callbacks.

@mikicho, would you like to give this one a try?

[mikicho]

Sure! I'd love to contribute to this one...
I'm looking into it.

[mikicho]

@kettanaito I need clarification on what you have in mind.
How is it different from what we currently have?

export async function handleRequest(options) {
  const handleResponse..
  const handleResomposeError..
  ...
  const result = await until...
 if (result.error)... // a.k.a onReject
 if (result.data)... // a.ka onResolve
}

[kettanaito]

Right now we have cases where rejections can be translated to successful response handling:

interceptors/src/utils/handleRequest.ts

Line 76 in 7e62e17

return await handleResponse(error)

And successful responses translated to errors:

interceptors/src/utils/handleRequest.ts

Lines 47 to 53 in 7e62e17

	if (response instanceof Error) {
	options.onError(response)
	}
	// Handle "Response.error()" instances.
	else if (isResponseError(response)) {
	options.onRequestError(response)

This all is intended but reading it is a bit confusing. So I proposed to have higher-level onResolve and onReject callbacks within the handleRequest function to make it easier to read. It's much easier to understand "onResolve triggered with an error, so treat it as an error" than "successful response callback triggered with an error, so it's an error". Do you see my line of thinking?

[kettanaito]

Released: v0.38.4 🎉

This has been released in v0.38.4!

• 📄 Release notes
• 📦 npm package

Make sure to always update to the latest version (npm i @mswjs/interceptors@latest) to get the newest features and bug fixes.

---

Predictable release automation by @ossjs/release.

[mikicho]

Reopen this because current implementation does not propagate the error and destroy the socket yet.
So, if we want to enable errorWith({a:1}); we need to:

1. to remove the if from here
2. Make onError accept object (code)

But it's impact on all clients which cause some test to fail

[wagenet]

I hit an issue that looks the same. I've attached the Claude analysis and I've also got Claude's attempted fix in a branch on my fork. I've validated the suggested changes and they look correct to me.

---

Analysis by Claude (Anthropic) — errorWith with non-Error reasons, still reproducing on 0.42.3

Reproduction

Still reproduces on 0.42.3, after the TCP/TLS interception rework. Two of the three call forms documented on RequestController.errorWith() hang, including the no-argument one:

import https from 'node:https'
import { ClientRequestInterceptor } from '@mswjs/interceptors/ClientRequest'

const interceptor = new ClientRequestInterceptor()
interceptor.apply()
interceptor.on('request', ({ controller }) => controller.errorWith(REASON))

https
  .request('https://example.test/', (res) => console.log('response', res.statusCode))
  .on('error', (e) => console.log('error', e.message))
  .end()

REASON	result on 0.42.3
(omitted)	hangs
new Error('boom')	errors correctly
{ message: 'boom' }	hangs
'boom'	hangs

Where the reason is dropped

src/interceptors/http/source.ts and src/interceptors/XMLHttpRequest/xml-http-request-proxy.ts both guard on reason instanceof Error. src/interceptors/fetch/web.ts forwards every reason via responsePromise.reject(reason), so the three interceptors disagree about what the same public API accepts.

The failure mode is a hang rather than an error: RequestController has already moved to ERROR and resolved #handled, so nothing downstream responds to or errors the request, and the consumer waits forever.

Downstream impact

This is the underlying cause of nock/nock#2789 — nock's replyWithError() accepts a plain object and passes it straight to errorWith(), so .replyWithError({ message: '...' }) hangs until the test framework's timeout fires. That issue is marked resolved in nock@15.0.0-beta.8, but it still reproduces on nock@15.0.0-beta.14 with @mswjs/interceptors@0.42.3, because the reason is dropped in interceptors rather than in nock.

Candidate fix

Branch: main...wagenet:interceptors:fix/error-with-arbitrary-reasons

It forwards the reason as-is in both sources, matching fetch. socket.destroy() and XMLHttpRequestController.errorWith() both accept arbitrary values; with no reason the socket is destroyed cleanly and the client sees ECONNRESET. Same idea as the closed #791, rebased onto the current layout.

Adds test/modules/http/response/http-error-with.test.ts covering all three documented forms — two of three fail without the change. test/modules/http 220 passed, test/modules/XMLHttpRequest 112 passed, pnpm build clean. Two pre-existing failures unrelated to the change, both of which also fail on an unmodified checkout in the same sandbox: forwards ECONNREFUSED error given a bypassed request, and a pnpm typecheck error in test/modules/http/intercept/http-connect.test.ts.

Two open design questions for the maintainers: whether non-Error reasons should be coerced into an Error rather than forwarded verbatim (forwarding preserves the consumer's error shape, which is what nock depends on), and whether this belongs in the handleRequest onResolve/onReject refactor sketched earlier in the thread instead of at the source level.