authExchange duplicating operations?

[jbalke]

I'm new to urql so not ruling out that I've made a mistake somewhere...

For background, I'm building a NextJS app with next-urql.

Initially, I implemented an authExchange (JWT) based on this gist: https://gist.github.com/kitten/6050e4f447cb29724546dd2e0e68b470. All worked fine. Some time after switching to the official exchange-auth package I noticed my backend receiving duplicate mutations (what tipped me off were the primary key violations on registering new users). Urql devtools has since confirmed that all of my queries/mutations are firing off in duplicate; one execution command resulting in two results within milliseconds of each other, all identical keys.

In a process of elimination, I discovered that the duplicate operations(?) only occur when using the new exchange-auth package. I'd post my authExchange config but it's practically identical to the documented example, other than minor implementation details such as how I get/set my access token, identify auth errors and log users out.

So I'm at a loss here. Is there anything I can do to debug further?

Btw, this is what my exchanges looks like: [devtoolsExchange, dedupExchange, cache, retryExchange(options), errorExchange, fetchOptions(ctx), authExchange({/* auth config */}), ssrExchange, fetchExchange].

[kitten]

That's pretty odd! Can you post a small code snippet of your authExchange config please? I'm confident I can debug this, but I'd need to see whether it's a mistake in the config first. 🤔 It's possible it's misidentifying a mutation response as an auth error and is sending a second one possibly.

[kitten]

is the argument-less isAccessTokenExpired() call intentional?

[jbalke]

Yes, the access token is stored in a module-scoped variable, so enclosed by the utility functions (or was my intention 🤔)

[kitten]

Hm, I believe that would be alright, but you’ll have to be careful with race and sync conditions. Since the token is also stored in the authState your isAccessTokenExoired function will basically trigger getAuth to fetch a new one and sync it back. But again, that should be alright;

Does the problem disappear if willAuthError always returns false however?

[jbalke]

Ok, when willAuthError only returns false the issue doesn't occur.

So I reverted the change and amended isAccessTokenExpired to accept a token and not refer to the module-scoped variable, but the issue persists. This change is still in-place.

From what I've observed from a cold login, a scenario where my login mutation fires twice, this is the flow (a successful login will return an access token and set the refresh cookie):

willAuthError -> true
--authState is null

getAuth - initialise
--NO ACCESS TOKEN 

(not yet have http-only refresh token cookie)

addAuthToOperation -> operation
--no authState
addAuthToOperation -> operation
--no authState

(a login mutation completes, access token set, refresh http-only cookie set)

willAuthError -> true
--authState is null

getAuth - initialise
--GOT ACCESS TOKEN

addAuthToOperation -> operation with fetchOptions
addAuthToOperation -> operation with fetchOptions

I'm still digging around but thought you might see something I've yet to wrap my head around...

[kitten]

Ok, I may have an idea of what's going on. I currently suspect that this call is duplicating the operation that has refreshed the authentication state: https://github.com/FormidableLabs/urql/blob/a770f18005c395245725e853d36246111591c37f/exchanges/auth/src/authExchange.ts#L155

[kitten]

I've just opened a PR to fix this issue and I believe I've tracked down what's causing this. #1075

If you don't mind, you can test this out for me by installing it from Codesandbox CI ❤️ Basically just set the version in your package.json for @urql/exchange-auth to "https://pkg.csb.dev/FormidableLabs/urql/commit/791f05aa/@urql/exchange-auth"

[jbalke]

Looks like you got it, no more duplication. Nice one!

[kitten]

Awesome! This has also just been released :) https://github.com/FormidableLabs/urql/releases/tag/%40urql%2Fexchange-auth%400.1.1