Use `serialize-error` module (`Error#cause` support)

[fregante]

I noticed that RTK’s error serialization is rather simple:

redux-toolkit/packages/toolkit/src/createAsyncThunk.ts

Lines 94 to 107 in 64a30d8

	export const miniSerializeError = (value: any): SerializedError => {
	if (typeof value === 'object' && value !== null) {
	const simpleError: SerializedError = {}
	for (const property of commonProperties) {
	if (typeof value[property] === 'string') {
	simpleError[property] = value[property]
	}
	}
	return simpleError
	}
	return { message: String(value) }
	}

For example this does not support nested errors, like the new cause property: https://v8.dev/features/error-cause

I know RTK supports specifying a custom serializeError as an option, but it'd be great to support the cause property out of the box, perhaps using an existing solution for error serialization:

• https://github.com/sindresorhus/serialize-error

[phryneas]

Honestly, this is working exactly as intended here.

createAsyncThunk knows two different kinds of errors:

• known errors - this would be this kind of error: you know that they will happen, you know they can have a specific structure. You should handle those in your code and use rejectWithValue.
• unknown errors - this could be an access to undefined.something, an out-of-bounds array access, a bundler error that only surfaces at runtime or a string that is being thrown somewhere in a library you are consuming and that you don't expect. We don't know anything about those errors. So the code you are pointing to tries to get them into a "predictable shape" so they can be at least handled at some way in the end.

So in the end: you should probably handle those errors and use rejectWithValue, or your well-known errors will get mixed up with unpredictable stuff.

[markerikson]

It'd be easy enough to add another field to the known list, but yeah, I don't want to add another dep here.

[markerikson]

Going to close this for now - I don't think this is urgent enough for us to change.

[kasparkallas]

I'd also like to see Error.cause serialized because it's a good convention which is now supported both in Node and browsers. I would expect to see it on the SerializedError object as well.

Or possibly provide a way to override serializeError for RTK-query?

[phryneas]

@kasparkallas that hasn't come up yet. If you'd like to make a PR in that direction, we'd be interested.

[kasparkallas]

A. Make it possible to override serializeError for RTK-Query
B. Add error's cause field to the known list and recursively serialize the errors (i.e. chain the errors)

Interested in both?

Here are some references to evaluate the urgency of B:

• error.cause browser support (part of ES2022): https://caniuse.com/mdn-javascript_builtins_error_cause
• error.cause added to Node 16.9: https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG_V16.md#16.9.0
• error.cause added to Node documentation: doc: document ES2022's Error "cause" property nodejs/node#43830
• error.cause added to TypeScript: TC39 proposal - Error.cause property microsoft/TypeScript#45167

[kasparkallas]

Ping! @phryneas @markerikson

[phryneas]

Honestly, at this point only interested in B - A would probably make the types explode.