The Same Password Worked in One Office and Failed in Another, in Two Different Ways

I’d used a password minutes earlier to confirm a new process worked at all. It went through cleanly. I tried the same password, same account, in the system a customer would actually use, and got two rejections back to back, worded nothing alike:

System one: “the password is invalid.” System two: “we couldn’t verify who you are.”

Same account. Same moment. Two systems, two different complaints, and the password I’d just watched work minutes earlier. That contradiction was the whole puzzle.

Two different locations turned out to each keep their own stored copy of that password, both attached to the same account name, which is exactly what made this disorienting. One office had the current password. The other had a leftover copy from before it was last changed, and nobody had noticed the two had drifted apart.

That stale copy fed two separate systems at the second location, an older one and a newer one, both checking the same stored password against every request. One bad copy, checked twice, produced two unrelated-sounding complaints from two different places at once. For a while it genuinely looked like two separate bugs, each needing its own investigation, before both traced back to the same stale copy.

Finding that took longer than fixing it did. Once I knew the real cause, there was an actual choice, and neither side of it was free.

Fix the one location I’d just found broken: a few minutes, problem solved for the customer standing in front of it right now.

Or assume every other location holding a copy of that password is carrying the same stale version, and check every one of them before calling it done: real time, several places instead of one, no customer waiting on it today.

I took the fast fix first, because someone was waiting on it. I didn’t call it done there. What I wrote down for the next check was smaller than “fixed”: fixed at this location, still unverified everywhere else that stores its own copy of the same password.

A stale copy in one place is rarely the only stale copy of that thing. The other locations are still out there, holding whatever version they were last given, until someone goes and checks.

dxdev LESSON · paste into your AI coding agent
LESSON: Two systems rejecting the same password with different error messages points to two stored copies, not two bugs
SOURCE: dxdev.com/blog/2026-06-03_same-password-worked-in-one-office-and
WHAT HAPPENED: A password confirmed working in one system failed immediately afterward in two other systems, on the same account, with two unrelated-sounding error messages. It looked like two separate bugs until both traced back to one cause: a second location kept its own independently stored copy of the password, left over from before the most recent change, and that single stale copy fed two of its own systems, producing two different-looking complaints from one root cause. The location that had a customer waiting was fixed first, but the fix was explicitly logged as resolved at this location only, unverified everywhere else that keeps its own copy of the same password, rather than closed as fully done.
THE RULE: When the same credential produces different, unrelated-sounding failures across multiple systems at once, suspect multiple independently stored copies that have drifted apart rather than multiple unrelated bugs, and a fast fix at the one location someone is waiting on is not the same as having verified every other copy of the same stored value.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Any credential, config value, or setting stored independently in more than one system or location rather than read from one shared source of truth.
      2. Any incident closed as fixed after patching the first location found, with no explicit note of which other locations holding the same value remain unverified.
      3. Two or more differently worded error messages from different systems occurring on the same account or request at the same time being investigated as separate bugs rather than one shared root cause.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.