An order that changed under you is not saved over

[sridharkalaibala]

A handset sends the whole order when it saves, and the till keeps only what arrives:

const finalItems = updatedItems.filter((ex) => incomingProductIds.includes(String(ex.item_id)));

That is not a mistake. It is how a cancelled dish gets cancelled.

It is also how a floor with several handsets loses food:

Waiter A adds a biryani at 19:00. Waiter B saves at 19:01 from a screen opened at 18:58. B's list has no biryani in it, so the till removes one the kitchen has already cooked.

The bill goes out short and nobody is told: not A, not B, not the kitchen, and not the shop, which has just given away a plate of biryani with nothing recording that it did.

The guard

A caller may say which version of the order it was looking at (seen_at). A save written against an older one is refused with order_changed and the moment the order actually changed, so the client can reload, show what happened, and let a person decide again. Only a person knows whether that biryani was meant to go.

What it deliberately does not do

• Silence still means yes. A caller that sends no seen_at is served exactly as before. Handsets already in shops are older than this code, and refusing their saves would turn a bug that loses one dish into one that takes no orders at all.
• An unreadable timestamp is not a conflict. That is a caller this check cannot help, and blocking it helps nobody.
• An order nobody has ever updated is judged by when it was created, so a first edit is guarded too rather than waved through.

Tests

Against a real mongod, because the question is what the database ends up holding.

✓ IS REFUSED, and the dish the other waiter added is still there
✓ says when the order actually changed, so the client can show it
✓ goes through, and a dish left out is still cancelled
✓ a caller that says nothing is served exactly as before
✓ an unreadable timestamp is not treated as a conflict
✓ an order nobody has ever updated is judged by when it was created

Three fail without the guard. The other three exist to catch the guard overreaching and pass either way - in particular, leaving a dish out must still cancel it, which is the behaviour this sits in front of.

The captain side, which sends seen_at and shows the waiter what changed, follows in Posnic/captain.

[github-actions]

Merged to develop. Anyone can test this - you do not need write access.

Try it at https://develop.posnic.io, or run it yourself:

git fetch origin develop && git checkout develop
npm install && npm --prefix api install
npm run dev   # then http://localhost:3000

When you have tested it, say what you did and what happened, and set
QA passed or QA failed. If you cannot set labels, just comment -
a maintainer will.

Reporting that something is broken is as useful as fixing it. It is
better found here than by a shopkeeper.