Custom errors thrown in onRequest do not get proper code set in onError

[EvHaus]

What version of Elysia is running?

1.1.5

What platform is your computer?

Darwin 23.6.0 arm64 arm

What steps can reproduce the bug?

When using custom errors inside an onRequest() handler, they don't seem to be handled properly inside the onError handler. See example below:

class APIError extends Error {
	public readonly message: string;
	public readonly status: number;

	constructor(status: number, message: string, options?: ErrorOptions) {
		super(message, options);

		this.status = status;
		this.message = message;
		this.name = 'APIError';
		
		Object.setPrototypeOf(this, APIError.prototype);
		Error.captureStackTrace(this);
	}
}

const errors = new Elysia()
	.error({ APIError })
	.onError({ as: 'global' }, ({ error, request, set, code }) => {
		// The bug is here. For the "Not authorized" error, this
		// coming back as "undefined". I am expecting it to be
		// "APIError" instead.
		console.log(code);
	});

const requestHandler = new Elysia().onRequest((context) => {
	throw new APIError(403, 'Not authorized');
});

const app = new Elysia()
	.use(errors)
	.use(requestHandler)

What is the expected behavior?

If I throw an error inside a route handler, onError properly detects it and sets the code to my errors custom name (APIError). However, if I throw that same error inside onRequest the code comes back as undefined.

I expect it to also be set.

The issue also seems to happen with regular throw new Error() errors too. I would expect the code for those to be set to UNKNOWN, but it's still coming back as undefined.

What do you see instead?

The code value is undefined.

Furthermore, if this is expected behaviour, then the output seems to be in violation of the types for code. Elysia says undefined is not one of the possible values. Might need to update the types.

Additional information

No response

Have you try removing the node_modules and bun.lockb and try again yet?

Yes

[SaltyAom]

Fixed with dc1f059, published under 1.1.6

[EvHaus]

Thanks for the fast turnaround. Confirmed this is fixed in 1.1.6