Long running query saving to wrong query key
Hi,
Having a particular issue and I thought I'd pick the brains of the lovely people here. So I am kicking off a long running query with the following query key:
["studies", connectionId1, [page1, page2]] <-- KEY1
The query can sometimes take 10-15 seconds to respond (thank god for RQ caching!). I'm going to call this QUERY1
During that time the user can change connection, which changes the key to:
["studies", connectionId2, [page1, page2]] <-- KEY2
This then of course kicks off another query: QUERY2
The problem I'm having seems to only affect Safari (Chrome & Edge seem to behave). When QUERY1 returns, the data gets added to KEY2 data and displays to the user, even though the data belongs to KEY1.
I am already attempting to cancel the query when the user changes connection (through an abort signal and through cancelQueries(<key1>))
I am currently working around the problem by using a useRef for the connectionId and when axios returns, I check the queryKey against the connectionId ref and bin the data (and removeQueries) if they don't match. However, it feels like there should be a better way where I can keep the data and have it saved to the correct key.
I can have a go at doing a minimal reproduction of the code if needs be, but thought I'd post this first to see if someone could immediately point to the problem!
Thanks!
1 Reply
foreign-sapphireOP•3y ago
OK, spotted something on Edge/Chrome. Where Safari saves QUERY1 to KEY2 in this instance, what Chrome/Edge does is not save the data returned from QUERY1 to any key - it seems to just bin it. I have tried going back now to not cancelling queries. I just let RQ get on with its thing and the data from QUERY1 is either saved to the wrong key (Safari) or not stored at all (Chrome/Edge). Any suggestions would be great!
I also spotted that if I change back to KEY1, it calls QUERY1 again (even if the first query isn't yet complete?). Wondering if there is a problem with the keys here maybe?
OK, as it turns out - solved it (well, actually, my boss did). Both calls for QUERY1 and QUERY2 looked the same to Axios (same URL), so it 'bundled' the responses onto one call which gave the odd behaviour.