The response is arrogant and irresponsible and not necessarily right either. This attitude is precisely the reason why most software is shit that requires constant manual babysitting. Bugs like this are no big deal until they are - even something insignificant as an item missing from the inventory can become a source of drama if you promised exactly this item to your child as a christmas present.

I just had a look at the OpenCart issue tracker and its not an isolated incident. There's a bunch of closed issues where the devs were incredibly rude to people while dismissing their concerns. Its true that in many of these cases the issue wasn't with OpenCart, but they could have just said "This issue isn't with OpenCart, its <blah>, closing." Not stuff like (and this is a real comment by a dev of OpenCart): "you are a moron! svg is not an image format!" and then when other people tried to help: "don't reply to this guy hes a scumbag". Riiiiight. Often the issues were closed without response and when the submitter asked why, they get an incredibly rude and arrogant response. I hope I never have to work with these assholes.

I reported an issue about them using SHA1 for password storage years ago. I was insulted and attacked personally, called a spammer, blocked, etc. So I washed my hands of the project, when I was considering it for a project at work. (I looked at password security first...)

It's funny, but the dev's response has since "disappeared". Still some ignorance in the thread (thinking that multiple layers of SHA1 was safe) but hopefully history has vindicated my position at that time.

Never use OpenCart for anything. There's no point, when you'll be insulted and unsupported. And don't work with the owner/contributor: https://github.com/danielkerr

There's quite a few "fun" OpenCart issues listed here whoever is interested: https://github.com/nikolas/github-drama

The dev is indeed really incompetent for behaving like that.

I love how in the password hashing one he first says something like "ok doesn't look too hard to do X" and then shortly after "I'm closing this, its a waste of time". Wow.

Also, his response here is amazing: https://web.archive.org/web/20160120051637/https://github.co...

Items cannot be shipped sometimes. In real life, that happens way way way more often due to other circumstances then due to race conditions. Staff breaks the last item. Manufacturer sent a box with 100 items but it only contained 99. The color of the shelf stained the last item. Etc etc etc.

Think about it: Depending on the shop software, two orders need to be placed within a few milliseconds. Containing the same item. And the item has to be very low on stock so the two orders cannot be fulfilled. That is a very very rare event. It's almost a theoretical event only.

I have seen a bunch of companies grow an online business. There were tons of pain points. This race condition was none of them.

It may be rare in this context. But a common requirement in asset management is eg: account holder X has a regulatory constraint that they may only control 5% or less of securities in the ABC industry across all accounts. So all trades must be validated that they don’t cross this line. In real life, the account holder may decide to sell shares of one company from the ABC list from one account so they can buy other shares from the list in another account.

The serializable isolation level does not guarantee reporting this correctly, and a concurrent process reading account balances could see a situation where account holder X is out-of-bounds of their regulatory constraints, despite the account holder themselves taking great pains to act lawfully.

For applications like this, strict-serializability is required. You can read more about isolation levels and anomalies in the article from comp sci Professor Daniel Abadi: https://fauna.com/blog/introduction-to-transaction-isolation...

Right, this is what happens with eventually-consistent systems. In the case of a retail system most failures are easily resolved by either resulting in delayed delivery, drop-shipping, or refunding the customer's order. It's not the end of the world.

Even banking works like this because settlements are done asynchronously. Some years ago there were several instances of an attack where someone got a hold of a rich middle easterner's debit card number and PIN, found a way to set the withdrawal limit up, then had crews of people hitting every ATM in Manhattan in one day. They were able to steal millions of dollars because the balance check was in real-time but the settlements weren't (so the balance was not drawn down).