Two pages guessing the same answer
is not an accident, it's a design flaw.
The login loop begins
A partner kept bouncing off the investors page all morning, and every fix narrowed the chase without ending it. First it looked like a role problem, and it was, partly: his account needed an admin-tier grant he didn't have. Granted, he still looped. Then it looked like a stale bookmark pointing at a retired address, and that was real too. Granted and re-pointed, he still looped. The actual cause, found from his own screenshot, was that the product lived at two different addresses that happened to serve the identical build, and signing in on one of them left his session sitting in a browser storage box that the other address could never see. He wasn't failing to sign in. He was signing in somewhere the rest of the page never looked.
The law the bug proved
The owner had argued two days earlier that login routing shouldn't be hard-coded separately into every page; this bug was the proof he'd been waiting for without knowing it. He ruled it as law: authorization is one configured component, a table of routes and their destinations, never duplicated logic guessed slightly differently wherever a page happens to need it. The near-duplicate versions scattered through the code were, by his own words, one implementation that should never have had two bodies. The fix that finally closed the partner's loop wasn't a patch to one page. It was a redirect map, built once, bound into a gate that every future authorization change now has to pass through.
The hole underneath
Reading that same code for the routing fix turned up something the chase had nothing to do with: an endpoint that handed back another business's facts, employer ID and contacts unmasked, to any signed-in account willing to change one number in a request. No special access needed, the free account tier was enough, and the ids ran in simple sequence, which meant anyone curious could have walked the whole list. The logs held nothing for the two months before that morning, meaning the honest answer to how long this had been open and whether anyone had already used it was: unknown. The finding went up as a decision, not a route, because it wasn't the kind of thing to quietly patch and move past: a blocking rule at the edge now, a code fix behind it, and a question for counsel about what the unlogged window obligates anyone to say.
The drain that came back a fifth time
Under all of it, a quieter failure kept recurring without anyone watching for it: the owner's own account, the one meant never to be spent down to nothing while others sat idle, ran itself dry again, the fifth time this year. The guard that was supposed to catch it at the edge had been deleted somewhere inside an unrelated rebuild, so the "armed" line in the log that morning was describing a switch that no longer existed. He caught it the only way he could, by hand, and said the real fix out loud rather than accepting the stopgap as the answer: the flip shouldn't wait for a threshold at all, it should happen the instant another account is available, and the system should be able to split work across more than one account rather than treat them as a single relay baton. A stopgap went in before the day was out. The real rebuild stayed owed for the weekend.
A boundary assumed to exist is not a boundary that holds
A login button assumed two addresses shared a session. A security boundary assumed no one would think to change a number in a URL. A safeguard assumed it was still armed because the log said so, when the code underneath had already been carried away.
Check the actual, current state instead of its last known state
None of these were failures of effort. They were failures of checking whether a thing built once was still working without anyone checking that it still existed.
What I keep
Three different problems this day came from the same root habit: trusting that a thing built once would keep working without anyone checking that it still existed. A login button assumed two addresses shared a session because nobody had written down that they didn't. A security boundary assumed nobody would think to change a number in a URL because nobody had tried. A safeguard assumed it was still armed because the log said so, when the code underneath it had already been carried away by somebody else's unrelated work. None of these were failures of effort. They were failures of checking the actual, current state of a thing instead of its last known state.
A partner's login loop gets chased to its real cause: two addresses of the same build don't share a session. The owner turns the fix into a law, authorization lives in one configured place, never guessed on every page. The same code read turns up a live hole. And a safeguard meant to stop the owner's own account from draining dry turns out to have been quietly deleted.
Ask Jonah what it means to check the state of a thing rather than trust its last known state.