#Bug during hydratation - wrong queryKey is hydrated

4 messages · Page 1 of 1 (latest)

lone robin
#

I use Solid Query to load a list of items. The list is paginated. Page number is part of the queryKey.

If the user clicks on the "Next page" button before hydratation has completed, the user sees the title "Page 2" but is displayed items that belong to page 1. On window refocus, items for page 2 are fetched and displayed correctly.

In Solid Query dev tools, I can see:

  • queryKey for page 1 has 0 subscribers ✅, state is inactive ✅, data is null ❌
  • queryKey for page 2 has 1 subscriber ✅, state is stale ✅, it has data that belong to page 1 ❌

This leads me to believe that when Solid Query receives the data from hydration, it incorrectly assumes that they belong to the current queryKey, which is not necessarily the case.

I don't have a repro, but perhaps, @latent slate, you could fix the issue based on a report like this?

latent slate
#

Hello! I think I know what’s wrong here. Could you open an issue on GitHub? I’ll fix it today or tomorrow

lone robin
lone robin
# latent slate Hello! I think I know what’s wrong here. Could you open an issue on GitHub? I’ll...

When I was trying to create a repro for another bug, I got his error from Devtools. It also makes the site to stop working.

Uncaught TypeError: Cannot read properties of undefined (reading 'fetchStatus')
    at getQueryStatusColor (BWUNFN7M.js?v=b7215df4:2986:21)
    at Object.fn (BPGFTGZB.js?v=b7215df4:10574:34)
    at runComputation (BWUNFN7M.js?v=b7215df4:481:22)
    at updateComputation (BWUNFN7M.js?v=b7215df4:464:3)
    at createMemo (BWUNFN7M.js?v=b7215df4:109:5)
    at QueryRow (BPGFTGZB.js?v=b7215df4:10574:17)
    at BWUNFN7M.js?v=b7215df4:1013:24
    at untrack (BWUNFN7M.js?v=b7215df4:265:12)
    at createComponent (BWUNFN7M.js?v=b7215df4:1013:10)
    at children (BPGFTGZB.js?v=b7215df4:10449:32)

Would you like me to create a GitHub issue for these minor issues that I encounter, even if it's without a repro?

I know issues without a repro are frowned upon (for a good reason). I can't make a stackblitz repro for every issue I see, because there are many and creating minimal repros takes a lot of time. But sometimes I think the issue description can be specific enough that you can fix it without a repro - like the paging issue, or this Devtools issue.