← All tests

Order Management ↔ Kitchen status sync STAGING

Narong (2026-07-22): moving an order into Preparing on the Kitchen Display didn't change anything on the Order Management screen — the status was stuck. Root-caused + fixed, verified live on get-coffee.staging. No migration.

Root cause. Order Management derives each order's status from kitchen tickets (fulfillmentForOrders), matching them by (shopId, orderName) and keeping the highest of new>preparing>ready. But order_number is only unique within a session (the register's sequence resets each shift), so it repeats day-to-day. On get-coffee.staging, order POS…0002 had three tickets piled up across days (07-10 preparing, 07-14 new, 07-21 served); the stale 07-14 new ticket outranked the real one and pinned the order to Pending forever. This hits prod too — any tenant open more than one day gets cross-day order_number collisions.

Fix — two layers. (1) Read-side (shipped first, no migration): match tickets by (sessionId, orderName) — a session isolates a day's orders — taking the latest ticket by queued_at. (2) Robust structural fix: add an order_id FK to cafe.kitchen_orders (migration 20260722120000 + backfill), have createKitchenOrder write it, and match on it directly (with the (session,name) layer as a fallback for legacy/orphan tickets). Now a ticket is bound to its exact order UUID — collisions are impossible.

Live proof (get-coffee.staging, order POS…0001)

The order's kitchen ticket is moved new → preparing (Narong's exact action); nothing else changes.

before — ticket new — **Before ·** ticket `new` → Order Management shows **Pending 1 · Preparing 0**. (Also note `POS…0002` is already correctly **Closed 1**, not stuck-Pending — the stale-ticket conflation is gone.)

after — ticket preparing — **After ·** same order's ticket moved to `preparing` → **Pending 0 · Preparing 1**, row status flips to Preparing. The Kitchen change now syncs.

Checks

Typecheck (`tsc --noEmit`)	clean
Logic verified against the real staging repro data (old=Pending wrong → new=Closed correct)	pass
Live E2E on get-coffee.staging — move ticket new→preparing, Order Management updates	pass
order_id FK: migration applied on staging Neon; local probe (order_id wins over stale legacy + fallback); staging E2E via order_id-linked ticket	pass
Staging smoke regression	5/5

Read-side fix: nix-cafe staging cb20ddb. Robust order_id FK: nix-cafe staging 7d4ca5b (Worker d2bbda28) + nix-OS-backend staging 317e2c7 — migration 20260722120000. Parked for the scheduled prod promote (this one does add a migration — node migrate.js on prod).