Issue #3618650: Count a house-given place once, and put a reprice through the engine
The panel's total came to twice the basket's for an area whose places the house gives out, and the endpoint's tariff operation asked the engine nothing at all. Full account in the issue summary.
What changes
- A house-given place is read in the panel and set nowhere: it states the offer the house gave it at, and its area's block is the one surface that prices it. That block is rebuilt from those very seats, so pricing both counted every one of them twice.
- Repricing a held place goes through
holdInTransaction()with the held line in$releasing- the engine's exchange path. One call, one lock, the line given up under the locks before anything is checked, so every rule that governs taking a unit now governs a reprice: the tariff belongs to the resource, it prices the seat's grade, its allotment has a unit left, the per-order allowance permits it. - A refused reprice leaves the place theirs at the offer it sat at, so it is answered with the place still named as theirs, and the client states the reason instead of trying to take the place again.
Cost
Measured with the query logger, first operation in a fresh process: 13 queries to 31, against 17 for taking one place and 37 for giving one back and taking one in a single run. The eighteen extra are the rules and the give-back; it costs the same order as a click and takes one lock where the give-back-and-click-again route takes two.
Tests
Four kernel tests on the operation, which had none of any kind: the reprice that works, another resource's tariff, an offer that does not price the seat's grade, and an allotment that has run out. Three were seen to fail against the code as it stood. One browser scenario reads the panel's total for a house-given area, which no scenario had ever done.
Not fixed here: the front-being-served filter is applied where tariffs are read, not where a hold is validated, so any path can still name a withheld offer. Worth its own issue against the engine's rule set.