Right, that makes sense.
Ok; testing in the sample app, I cannot recreate what happens on my web app - but I have found some interesting things.
This is my event handler which is causing issues, for reference:
const onSave = async (updatedProfile: ProfileFormData) => {
// Do some processing of my form, then send network call
await updateUser(request).unwrap();
// Now update the user
await getAccessTokenSilently({ cacheMode: 'off' });
};
This doesn’t work; however this does:
const refreshToken = async () => {
await getAccessTokenSilently({ cacheMode: "off" });
};
const onSave = async (updatedProfile: ProfileFormData) => {
// Do some processing of my form, then send network call
await updateUser(request).unwrap();
// Now update the user
setTimeout(refreshToken, 0);
};
So moving the call from the job queue (running after awaiting a promise) to the event queue (like how setTimeout is implemented) fixes the issue.
This also works (confirmed by changing the username on the dashboard before trying, just swapping the order of the calls:
const onSave = async (updatedProfile: ProfileFormData) => {
// Now update the user
await getAccessTokenSilently({ cacheMode: 'off' });
// Do some processing of my form, then send network call
await updateUser(request).unwrap();
};
I tried to replicate this issue in the sample app, but I was unsuccessful; the below code works fine (which I think, should have the same issue?):
const handleRefresh = async () => {
const fact = await fetch("https://catfact.ninja/fact");
console.log(fact);
await getAccessTokenSilently({ cacheMode: "off" });
};
So I don’t know - maybe the RTK query mutation promise that I’m awaiting is doing something differently under the hood which affects things? I’m not enough of an expert in JS internals to know.
Anyway, for now I’m running with the setTimeout workaround; it seems the less hacky approach
