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.
If it gets fixed, maybe the devs reintroduce it on Halloween or glitch it to weird fake bios and characters.
It looked like a great effect.
That would be great, but hard to reimplement without it being an actual bug again.
deleted by author
deleted by author
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
This was a way, dare I say, cooler bug involving closures around
getGetServerSidePropsparameters.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.
That is very interesting. I'll keep an eye out for the commit that fixes it, I'd like to take a look!
Pushed
This is proof anyone can contribute to FOSS projects without having to know a single line of code.
Bless.
deleted by author
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.
We were all seeing the same stackers because we were all sharing the closure state.
This link download super slow for anyone else?
Also idk how I feel about getting tagged in bug reports now... jk, I'm down.
Catbox usually isn't this slow, if I ever see bugs like this in the future I'll use a different host.
deleted by author
deleted by author
Yep I see it. That is bizarre