Authentication Client caching BadRequest responses from create

[nborko]

I'm running the latest feathers version of everything, using the rest client with axios.

I have overridden the create method of my authentication service to return BadRequest in some cases. My issue is that after calling app.authenticate() and receiving the BadRequest error, subsequent calls to any other service also immediately returns the same BadRequest error without making an actual network request. Thus, I am unable to fall back to a non-authenticated service call when a login fails.

As far as I can tell, when the client runs calls the authentication hook in subsequent service calls, it keeps returning the same rejected promise stored in the authentication key (app.get('authentication'))

My current solution is to call app.authentication.reset() on the client side before making subsequent calls to a non-authenticated service. However, the documentation for the reset method reads, "Should not be called directly." Should I be doing something different?

Thanks

[jnardone]

We've seen weird issues with our authentication service when it returns non-401 errors and client state, to the point where we now have an after hook on our auth services that convert all 400-level error codes to 401s.

https://github.com/feathersjs/feathers/issues/1787

[sradevski]

Just to add some more context based on what I observed. I think the reason for this is, feathers assumes that we first check for the token validity, reauthenticate, and only then do server requests. If you do some requests in parallel, as noted in the issue, even if they are done to routes that don't require auth, those will be rejected with the reAuthenticate rejection error, so it seems all other feathers client requests wait for the authentication call to resolve. Calling reset is not an option for me, since I don't know if the token is valid or not until I call reAuthenticate, and I don't want to needlessly logout the user.

[daffl]

This was indeed a bug and will be fixed with #2892