One browser’s good manners are not a lock
A disabled button is one browser being polite. Two tabs or a retry still interleaved a delete and its inserts and doubled a venue’s hours. One batch fixed it.
Five Save buttons in the back office sat outside the dialogs our shared guard protects, so two taps in one turn sent two writes. Reading what each route did with the second write, four of the five were mild. Each landed on the same row and the user got what they asked for. The fault there is a button that does not respond, so somebody presses it again.
The one with teeth
Saving a venue's opening hours was different. The route updated the venue, deleted every dated row, then inserted the new dated rows one at a time. Two requests can interleave: delete, delete, insert, insert. Every special date ends up in the table twice, and a venue shows two different answers for one Sunday.
Disabling the button fixes that in one browser. It does not fix two tabs, two devices, or a request the network retried. Any of those reach the same interleaving with the button politely greyed out in both places.
The lock is in the database
The delete and the inserts are now one batch, which the database runs as a unit. The interleaving becomes impossible rather than unlikely, and a venue with ten dated rows goes from eleven round trips to one. The next day's walk of every screen found a second button on a different page posting to the same route. That is the whole argument for fixing the server side and not only the button.
The button guard was still wired, with care. Locating the call site by a line of text that two screens share put it on the wrong screen first, a sheet that already disabled its own button. Re-driving the five screens caught that, which is why we re-drive rather than trust a diff.