Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto handling of specific error types #202

Open
oudeismetis opened this issue Sep 17, 2024 · 3 comments
Open

Auto handling of specific error types #202

oudeismetis opened this issue Sep 17, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@oudeismetis
Copy link
Member

It would be great if you could set up a Collection Manager or an API and configure it with a callback for any and all calls that result in...say...a 401 error.

The main use case being when a user's token expires or gets deleted. There are certain critical API endpoints that should never fail for the user. If they do, then it likely means the users token is bad. In the callback I could then maybe call an endpoint to verify that their token is in fact bad and then, based on the result of that call, either redirect them to their dashboard or to the login page.

In my app currently, a 401 results in a broken page with nothing making it obvious that the user needs to log out and log back in. To fix that I'll have to go through all of my business logic, find every call to every critical API service and handle each one of those individually. Will then need to remember to do that for any new calls that are added to the business logic in the future.

@oudeismetis oudeismetis added the enhancement New feature or request label Sep 17, 2024
@paribaker
Copy link
Contributor

I like the idea of allowing custom callbacks in general, but I think the use case that you are referring to should get handled by the project. In our react side projects all 401 errors are handled using a generic 401 handler.
I also have an open PR in the bs to add one for the vue side.

@paribaker
Copy link
Contributor

Here is a sample:

axiosInstance.interceptors.response.use(
  (config) => config,
  (err: unknown) => {
    if (isAxiosError(err)) {
      logAxiosError(err)
      if (err.status === 401 || err.response?.status === 401) {
        const { clearAuth } = useAuth.getState().actions
        clearAuth()
        window.location.replace('/')
      }
    }
  },
)

The logic here does not redirect the user through the router but I think that can easily be changed!

@lakardion
Copy link
Member

lakardion commented Sep 17, 2024

This sounds like something that the axios client owns as Pari commented, it involves the interceptor.
So to my view this escapes the responsibility of the library considering the axios client is a parameter the user passes in

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants