A save that returns OK and writes the wrong row
The request succeeded. The screen said Saved. The value went to the wrong table entirely, and every test that checked the response was satisfied.
Mid-build on the settings work, a save started landing in the wrong place. Not failing — landing. The browser sent it, the server answered 200, the screen said Saved, and the value went into a table it had no business being in: the platform-wide row, meaning one venue's till had just set a value for every tenant on the system.
How it happened is embarrassingly ordinary
The new code looked up the venue to decide where to write. That lookup asked
for a column that does not exist on that table. The query threw. An existing
catch — put there years ago for the sensible reason that a
settings save should not explode if a venue lookup hiccups — swallowed the
error and returned nothing. With no venue, the code fell through to the branch
below it, which is the platform-wide write.
Every step behaved as designed. The defensive catch was defensive. The fall-through was the fall-through. Together they turned a typo into a multi-tenant data leak that reported success.
The test that caught it, and the one that would not have
The end-to-end check we run against every release caught this immediately, and only because of how it was written. It does not assert that the save returned 200. It reads the database afterwards and asserts which row moved — the vendor's row exists with the new value, the hall's row is untouched, and a sibling venue still resolves the old answer.
A test asserting the response would have passed. A test asserting the screen showed "Saved" would have passed. Both are the tests it is natural to write, because they mirror what a person does when they check by hand.
Two fixes, not one
Selecting only the column that exists fixes today's bug. The second fix matters more: a request that names a venue which cannot be read is now refused outright rather than quietly widening its own scope. Silent fall-through from a narrow write to a broad one is a bad shape regardless of what caused it, and the next typo will find a wall instead of a door.
If you are shopping for a system that will hold several businesses: ask how it fails, not how it works. Everything works in the demo.