Looking into it. Looks like I'm able to reproduce it. Super weird.
Could it be some kind of SSR caching issue? I don't see any graphql fetch calls with the temporary user profile data...
ETA: I do see the rogue user profile data in the HTML payload from the server, so that would seem likely ^ though idk why
reply
This was a way, dare I say, cooler bug involving closures around getGetServerSideProps parameters.
I thought I was being efficient by reusing them for storage inside the closure, but I was "enclosing" the changes to the parameters. The next time the function was called, it was using the enclosed values and not the parameters.
reply
That is very interesting. I'll keep an eye out for the commit that fixes it, I'd like to take a look!
reply
Pushed
reply
This is proof anyone can contribute to FOSS projects without having to know a single line of code.
Bless.
reply
deleted by author
reply
It's probably cache related but it could also be query params getting sent as null or something because it's the same handful of wrong users.
reply
We were all seeing the same stackers because we were all sharing the closure state.
reply