deleted by author
reply
Looking into it. Looks like I'm able to reproduce it. Super weird.
reply
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
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
This link download super slow for anyone else?
Also idk how I feel about getting tagged in bug reports now... jk, I'm down.
reply
Catbox usually isn't this slow, if I ever see bugs like this in the future I'll use a different host.
reply
deleted by author
reply
deleted by author
reply
Yep I see it. That is bizarre
reply
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.
reply
deleted by author
reply
That would be great, but hard to reimplement without it being an actual bug again.
reply