Name: [FIX] pos_restaurant: wait for the order sync instead of racing it

State: Failed finished in 5m

PR State: closed

PR Author: David Tran

PR Author Email:

PR: #1266

Committer: David Tran

Committer Email: david.tran@viindoo.com

Commit: c8e3d56da49963383aec992bebcb3ab7b128256d

Description:

                                            [FIX] pos_restaurant: wait for the order sync instead of racing it

The "Check if order has a server ID" step of the test_book_and_release_table
tour sampled the order's id exactly once and threw if it was not yet a number.
Nothing sequenced that sample after the syncAllOrders RPC that assigns the id:
the preceding waitForLoading() only waits for `body:not(:has(.loader))`, and
the step's own `trigger: "body"` matches immediately. Whether the step passed
was therefore decided by whether the server happened to answer first.

On Viindoo's runbot it does not. Subbuild 407980 shows the step running at
02:05:36,110 and the server logging "created pos.order #563" at 02:05:36,152 -
the assertion lost the race by 42 ms and the tour failed, even though the order
was created successfully moments later.

The margin is small and hardware-dependent, not caused by module load. Measured
across 24 runs at four addons-path scales (58, 126, 293 and 1330 installed
modules - the last exceeding runbot's own 1089), the server won locally by
+50..+93 ms every time, and a 23x growth in installed modules moved the mean by
only ~24%. Registry size, POS asset-bundle weight and third-party POS addons
were each ruled out as the mechanism; what differs is how fast the machine is.

Poll for the id with a deadline instead of sampling once, so the step waits for
the sync it depends on rather than racing it. The thrown error is unchanged, so
existing log triage still matches.

The usual idiom for a non-deterministic tour step is a more specific `trigger`,
letting the tour engine's own retry loop do the waiting - see 8cb86ec07ad5
"[FIX] lunch: fix non-determistic tour error". It does not transfer here: the
condition is JS model state (posmodel's pos.order id), not a DOM fact, so there
is no selector to wait on.

Verified by constructing the failure, since the race is won on the development
machine and cannot be reproduced there naturally. With a 400 ms sleep injected
into pos.order.sync_from_ui, the unfixed tour fails with exactly the runbot
signature ("FAILED: [7/10] ... Step Check if order has a server ID" /
"Order does not have a valid server ID", delta -360 ms). With that same sleep
still in place, the fixed tour passes all 10 steps (delta -320 ms - the server
is still slow, the step now waits for it). With the sleep removed the fixed tour
passes at +86 ms, back inside the natural baseline band, and the rest of the
pos_restaurant suite is unaffected (0 failed, 0 errors; the one skip,
test_13_crm_team, needs pos_sale and is pre-existing).
                                            

Branch: 18.0

Age:

Up-time: