I was at the funeral and customers kept ordering through the kiosk — holiday_mode 503 was missing from one endpoint

Mateus (45) runs Bairro Tasca in Lisbon's Alfama with a kiosk by the door for tourists. He took the bus to his home village near Vila Real for his grandmother's funeral, five days away. Flipped Holiday Mode ON before leaving. Came back to 31 ghost orders + 4 TripAdvisor 1-star reviews + one Google Maps rating drop + a Booking.com listing comment. thMenu support cracked it on the third look: kiosk submissions went to `/api/kiosk/order`, NOT `/api/orders`. The kiosk endpoint's tier-check SELECT only pulled `subscription_tier` — never `holiday_mode`. When kiosk shipped to Pro+ in PR #459 (2026-05) it didn't inherit the holiday_mode 503 short-circuit that the sibling order endpoints (orders, waiter-calls, bill-requests) already had. Classic sibling-endpoint hardening parity gap. **PR #660 batch X F2** fix: SELECT now also pulls `holiday_mode` + adds `if (rest?.holiday_mode === 1) return 503 holiday_mode_active` short-circuit matching `/api/orders` lines 286-292. Pattern: when a new endpoint ships, audit it against the generic state guards already in place on sibling endpoints — tier gate, rate limit, holiday_mode, shadowban, bill freeze, input bounds, idempotency-key format.

Related articles