[ssl-3]

Debouncing would be smart, sure. But sometimes, these sorts of embedded machines are weirder than that.

At Kroger-brand gas stations near me, I get to interact with the buttons on gas pumps to select options and enter a loyalty ID.

Those buttons have visible feedback on a screen, and also audible feedback consisting of a loud beep. And there's always delays between button press and feedback.

Some combination of debounce and wear might explain that easily enough.

Except... the delay between pushing a button and getting feedback is variable by seemingly-random amounts. The delay also consistently increases if a person on the other side of the pump island is also pushing buttons to do their own thing.

It's maddening. Push button, wait indeterminate time for beep, and repeat for something like 12 or 13 button presses -- and wait longer if someone else is also using the machine.

I can't rationally explain any of that variability with debounce.

[lazide]

They are running it on a Java VM in a container - on a 386?

Over WiFi?

[ssl-3]

Perhaps.

Or perhaps the original programmers skipped the class on concurrency 25 years ago, and nobody has subsequently bothered to pay anyone to update that part of the software.

[QuercusMax]

One time I decided to test whether these grocery story loyalty card XX cents off per gallon transactions were properly isolated, when my wife and I were both filling up vehicles at the same gas station at the same time. We both got the $0.50 discount per gallon with no problem. I'm sure there are lots of creative ways you can exploit the poor design of these things.