Error improvements

[fregante]

• Avoid circular references by moving around some error classes and error helper functions. Maybe as described in this comment:
  - utils/errors/businessErrors.ts
  - utils/errors/clientRequestErrors.ts
  - utils/errors/generic.ts
  - utils/errors/errorHelpers.ts
• Look for errors that are being passed around serialized
• Move selectErrorFromEvent/selectErrorFromRejectionEvent out of selectError
• Avoid NetworkErrorDetail/enrichBusinessRequestError duplication
• Possibly merge selectServerErrorMessage/selectNetworkErrorMessage into enrichBusinessRequestError so that AxiosError never makes it out out the latter
• Replace rejectOnCancelled with an inline cancellation mechanism

Follows

• #3372: Use only Error#cause, even outside ContextError #3073

[twschiller]

Look for errors that are being passed around serialized

The 3 places where serialization has to occur is: 1) messenger API, 2) IDB, 3) Redux store

[fregante]

Yes, but they should not leave those areas IMHO. If an error is received by those three, they should immediately deserialize it before calling external functions, although I haven't looked into where this could happen exactly in RTK.

The messenger for example does this internally for thrown errors; for passed errors (like for RECORD_ERROR) we already deserialize them on reception:

pixiebrix-extension/src/background/logging.ts

Lines 263 to 274 in 954e989

	maybeSerializedError: SerializedError,
	context: MessageContext,
	data?: JsonObject
	): Promise<void> {
	forbidContext(
	"contentScript",
	"contentScript does not have CSP access to Rollbar"
	);
	try {
	// Ensure it's deserialized
	const error = deserializeError(maybeSerializedError);

[twschiller]

Yes, but they should not leave those areas IMHO. If an error is received by those three, they should immediately deserialize it before calling external functions, although I haven't looked into where this could happen exactly in RTK.

RTK is just a nice toolkit for Redux. What's happening is that the error is getting serialized before it's placed in the store

Then, in our components we use hooks, e.g., const {data, error, isFetching} = useMyCustomQuery(params) to get that data out of the store. So we're have to do one of the following:

1. Modify the RTK library to deserialize the errors it passes back from its hooks, or
2. In each of our components deserialize the error coming from RTK

Option 2 is a non-starter -- it's too tedious/error-prone. Option 1 could make sense in the future

With respect to IDB, we could deserialize upon retrieval from IDB. However, there's some places where we store the errors in Redux. So we'd need to serialize before putting it into the Redux store there and then deserialize

All in all, our codebase really wants everything to be serializable 😄 . I think we're fighting an uphill battle against wanting to rely on classnames/prototypes/instanceof

[github-actions]

This issue will be closed in 7 days unless the stale label is removed, or a comment is added to the issue.

[github-actions]

This issue was closed because it has been stale for 7 days with no activity.