An order's state must stay in step with its held lines as a basket is edited, in both directions.
Empty to pending: BookingManager::holdGroup() transitions a new order from empty to pending after its first lines, but only when it creates the order. An order can rest at empty (its lines all released) and still accept appends; a later hold appended into such an order kept holding lines but stayed empty. The seat map reuses the session order this way, so a map-booked basket sat at empty while it held seats.
Pending to empty: the seat map releases seats directly, without recomputing the order state, so deselecting the last seat left the order pending with none. The cart's own removal already recomputes; the map did not.
Either gap is more than cosmetic: placeTransaction() only accepts pending or locked, so a workflow reaching its place step on an order in the wrong state is rejected.
Fix: holdGroup() moves an order from empty to pending whenever it ends up holding lines; SeatSelectionController recomputes after a release, mirroring the cart's removal. An append into an already-pending order still leaves the state to the caller. Kernel-tested in both directions.
Issue fork yoyaku-3611928
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
mably commentedComment #4
mably commentedComment #6
mably commented