The Konami Spam Guard That Never Guarded Anything
if (activated) return; was in the code the whole time. It just read a value from a render that had already ended.
This site has a Konami code. Up up down down left right left right B A, and every glass card gets a rainbow border, a Matrix rain overlay drops in for 2.5 seconds, and the achievement system gets an event. There was a guard so you could not spam it: if (activated) return. It never worked. Typing the code twice fast stacked two overlays and two toasts.
The keydown listener was registered once, in a useEffect with an empty dependency array. That is the right thing to do for a global key listener. The wrong thing was what it closed over. The handler called triggerEasterEgg, which was a plain function defined in the component body, and that function read activated from React state. The handler was created on the first render and never replaced, so it held the first render's triggerEasterEgg, which held the first render's activated, which was false. Forever. setActivated(true) re-rendered the component with a new activated and a new triggerEasterEgg, and the listener never saw either.
There was a second problem in the same ten lines. The sequence was state too, and the match check ran inside the setSequence updater, with triggerEasterEgg called from inside it. A state updater is supposed to be pure. In development React can run updaters twice on purpose, so the effect could fire from inside a state transition, which is exactly the place you cannot reason about.
The fix is boring. sequence and activated are refs. The handler reads sequence.current, appends the key, keeps the last ten, compares, and if it matches it resets the ref and calls trigger. The guard reads activated.current, which is the live value because a ref is one object shared across renders. The three timeouts that end the effect are tracked in a Set and cleared on unmount, because the old version leaked them if you navigated away mid-rain.
The same shape of bug was elsewhere in that pass. Alt+T was double-firing because two ThemeSwitchers each registered the shortcut. Ctrl+1 through 6 were being hijacked on /play by a global listener that should not have been there. All of them are one listener, registered once, holding values it should not hold.
The rule I came out with: a listener you register once may only read refs and call functions that read refs. If it reads state, it reads the state from the render that created it, and that render is gone.