4 ms·

Not that it's relevant to the issue at hand, but I'm curious about what kind of setup leads to "corrupt orders in the DB" and in what kind of business the corre

by mvdtnz 3y ago

Not that it's relevant to the issue at hand, but I'm curious about what kind of setup leads to "corrupt orders in the DB" and in what kind of business the correct response to such a situation is to simply delete the offending rows. Surely those orders are there for a reason?

AntonZ234 3y ago
The answer is actually a bit complex. I simplified in the article, the orders are in fact internal ‘missons’, that our operations team needed to execute (I work at an Agtech company, and each such mission is a drone flight above a field). Due to some bug, there were duplicate missions created, and it messed up the systems and confusing the operations team.
- mvdtnz 3y ago
  Ah that makes sense, thanks for the follow up.
laeri 3y ago
That can happen, I had this case with a local payment gateway. When a user started a checkout session we created a database object that tracked the specific checkout with an id the payment gateway handed back. When the user aborted the checkout the corresponding order within the gateway however was only kept for around 30 minutes and then deleted. This meant a checkout row in our database tried to associate an external order with an id for an object that didn't exist anymore. This lead to some errors when we tried to get data for these checkout items and got back that they weren't found.
michaelt 3y ago
Imagine your customers want to reserve some of your limited capacity, before they know precisely what they want to use it for. So you allow them to "check out" empty placeholder orders, to reserve their place in the queue. They edit the order later to add the details - and they very rarely forget, these being some of your most eager customers. (Yes it's an ugly hack, but business types love getting features on the cheap) Do that enough times and eventually someone will forget to edit the order, and at the front of the queue you'll find an order for nothing. Which downstream systems will quite reasonably not accept, as it's obviously corrupt.

by mvdtnz 3y ago

AntonZ234 3y ago

The answer is actually a bit complex. I simplified in the article, the orders are in fact internal ‘missons’, that our operations team needed to execute (I work at an Agtech company, and each such mission is a drone flight above a field). Due to some bug, there were duplicate missions created, and it messed up the systems and confusing the operations team.

mvdtnz 3y ago
Ah that makes sense, thanks for the follow up.

laeri 3y ago

That can happen, I had this case with a local payment gateway. When a user started a checkout session we created a database object that tracked the specific checkout with an id the payment gateway handed back. When the user aborted the checkout the corresponding order within the gateway however was only kept for around 30 minutes and then deleted. This meant a checkout row in our database tried to associate an external order with an id for an object that didn't exist anymore. This lead to some errors when we tried to get data for these checkout items and got back that they weren't found.

michaelt 3y ago

Imagine your customers want to reserve some of your limited capacity, before they know precisely what they want to use it for. So you allow them to "check out" empty placeholder orders, to reserve their place in the queue. They edit the order later to add the details - and they very rarely forget, these being some of your most eager customers. (Yes it's an ugly hack, but business types love getting features on the cheap) Do that enough times and eventually someone will forget to edit the order, and at the front of the queue you'll find an order for nothing. Which downstream systems will quite reasonably not accept, as it's obviously corrupt.