Home/Research

Fulfilment engineering

The right decision, in the wrong order

A duplicate-order detector flagged 52 orders as duplicates in one day. Roughly 29 customers still got the same parcel twice, because two automated steps ran in the wrong sequence.

Published 2026-08-24

The finding

In one measurement day — 24 hours of live orders — the duplicate-order detector flagged 52 orders as duplicates. Of those, 23 were cancelled. On the other 29, a label had already been printed by the time the cancellation was attempted, and a guard refuses to cancel a parcel that has already been dispatched. So roughly 29 customers received the same parcel twice.

The automatic labelling loop runs on its own schedule. It created the label in the gap between the moment the detector decided to cancel and the moment the cancellation reached the order. The guard then did exactly what it exists to do: it refused to cancel a parcel already on its way. Neither component was wrong. The detector decided correctly, the guard behaved correctly, and a dispatched parcel should not be cancelled. The defect was entirely in the sequence.

What each of those cases costs is return shipping paid in both directions, and a customer who receives two of the same thing.

The fix

The labelling service now asks the duplicate rule for its verdict on that one order before printing the label. If the verdict is cancel or hold, no label is made. The cancellation itself stays with the detector: there is exactly one rule, with two call sites, rather than two rules free to drift apart.

Any exception inside that check lets the parcel ship. That is deliberate: a good order held back by a bug in a safety check costs more than a duplicate that slips through.

Before it was switched on, the check was simulated against the 183 orders then waiting for a label. None was wrongly blocked.

Where we were wrong

Our own checker reported an alerting system as dead. It was not. A flag disabling customer-facing email was on, while internal alerts leave on a different path. The check was asking the wrong question: it measured the channel it knew about, not the channel the alerts actually use.

The same checker defined a duplicate more loosely than the rule it was checking — same phone and same items at any time, instead of within the rule's own window. Returning customers were counted as duplicates, and the rate it reported was not real.

The lesson: a checker greedier than the rule it checks produces false alarms. The cost is not the first false alarm; it is that the second time it cries wolf, nobody reads it. A check has to ask the same question as the thing it checks, in the same terms, or it is not a check.

Limitations

This is one fulfilment system. The counts come from one measurement day: 52 flagged, 23 cancelled, 29 already labelled. The check was validated in one simulation, against the 183 orders waiting for a label at that moment.

The sequencing failure is general; the counts are ours. Any system where a decision and its effect are separated by a queue, and where a second automation is free to act in that interval, can produce the same result. The figures above say nothing about how often it happens elsewhere.

Questions and answers

Why do customers still receive duplicate orders after a duplicate detector cancels them?

Customers can still receive duplicate orders because an automatic labelling loop may print a label in the gap between the detector's cancel decision and the moment the cancellation reaches the order. A guard then correctly refuses to cancel a parcel already dispatched. The detector and the guard both behave correctly; the defect is entirely in the sequence of the two automated steps.

How do you stop a label being printed for an order that should be cancelled?

Stopping a label for an order that should be cancelled means making the labelling service ask the duplicate rule for its verdict on that order before printing. If the verdict is cancel or hold, no label is made. The cancellation itself stays with the detector, so there is exactly one rule with two call sites instead of two rules free to drift apart.

Should a safety check block an order if the check itself fails?

A safety check in the duplicate-order fix described lets the parcel ship when any exception occurs inside the check. That is deliberate: a good order held back by a bug in a safety check costs more than a duplicate that slips through. Before switching it on, the check was simulated against the orders then waiting for a label, and none was wrongly blocked.

Why does a monitoring check that is stricter than the rule cause problems?

A monitoring check that is greedier than the rule it checks produces false alarms. In the case described, the checker counted returning customers as duplicates because it ignored the rule's own time window, so the reported rate was not real. The cost is not the first false alarm; the second time the checker cries wolf, nobody reads it.

How can a health check wrongly report an alerting system as dead?

A health check can wrongly report an alerting system as dead when it measures the wrong channel. In the case described, a flag disabling customer-facing email was on, while internal alerts left on a different path. The check measured the channel it knew about, not the channel the alerts actually used, so it reported a working alerting system as dead.

All research