Review error handling in RTK

[fregante]

• From Use serialize-error module (Error#cause support) reduxjs/redux-toolkit#2392 (comment)

We never followed up on this suggestion by RTK authors:

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

Any improvement possible here? Feel free to close otherwise

Related

• RTK errors lose cause (the page editor HTTP error log is broken) #3613
• Error improvements #3372
• #3115 Workshop shows stale brick detail after save #4112 (comment)
• RFC: standardize error handling in React components #2937

[BALEHOK]

We can also review the appBaseQuery and the way we get error messages.

1. A new Axios instance is created for every request. This is not optimal.
2. Axios throws a rich error object, which we have to serialize any way to store in Redux losing all the benefits of that AxiosError. We possibly could switch to RTK fetchBaseQuery which is meant to work with Redux and eliminate the need for serialization entirely. This may involve the way we get error messages (see p.3).
3. Getting the error message doesn't have to rely on isAxiosError method. If an error has a response property, we can treat it as an API error.

[fregante]

3. The logic for server errors is not as simple as you'd expect

   pixiebrix-extension/src/errors/networkErrorHelpers.ts

   Line 176 in 3c62042

   export function selectServerErrorMessage(

[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.