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

State:

Building with script

PR State: open

PR Author: David Tran

PR Author Email:

PR: #1269

Committer: David Tran

Committer Email: david.tran@tvtmarine.com

Commit: a022a38c19285321c21f380e6955128acde21287

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: Not finished