>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3620032. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !323 >>> <h3>Problem/Motivation</h3> <p>A booker adding to a party they already hold is refused outright and told they cannot leave a place empty on its own, on a page that never offered them a place to leave. The house has hundreds of seats free. The booker chose nothing, so there is nothing they can act on: the sentence describes a decision the engine made.</p> <p>Two faults in one method, and the first hides the second.</p> <p>The party fills two rows and holds the first place of a third, so the run beside it is one longer than the ask. Most of the ask fits there legally, and <code>getBeside()</code> shrinks the take until it stops stranding the last place, which is correct and is why <code>extend()</code> declines to answer for the whole ask. <code>getGrowFromTheParty()</code> takes over: it seats what fits and sends the remainder down the ladder.</p> <p><strong>The remainder is judged against the row as it was read</strong>, not as the proposal will leave it. It sees the places it is about to sit beside as company for their neighbors, takes the seat that looks safe at one end of a stretch it is itself cutting in two, and strands the place at the other end. That take passes every check the strategy makes and is refused by the rule enforcing the same sentence under the lock. It also passes over a legal answer one row away, where the odd one out could sit leaving two places side by side.</p> <p><strong>The last-resort mark does not survive the merge.</strong> Where there is genuinely no legal answer left, the floor of the ladder seats the party anyway and marks the proposal the last resort it is, so the rule reads the mark and allows what it would otherwise refuse. That is the promise <code>allow_last_resort</code> rests on. The remainder's proposal is rebuilt carrying its closeness and not its two flags, so the seating admits nothing while proposing places it has already judged unavoidable. <code>getOverTheWholeParty()</code>, immediately below, takes care to preserve exactly these two flags and says so in a comment; its caller discards them before it is ever reached.</p> <p>Neither fault needs a setting to be wrong. <code>allow_last_resort</code> and <code>allow_together</code> were at their shipped defaults throughout.</p> <h3>Steps to reproduce</h3> <p>A venue of one section with rows of six, eleven and twelve places at one grade, and the orphaned-places rule attached with a minimum of two. Grow a party through the stepper, naming no place: six, then eleven, then one. It fills the first two rows and takes the first place of the third. Then ask for ten more. The house has eleven places free and the booking is refused.</p> <p>Add a fourth row of three and the refusal stands, although nine in the long row and one in the short row leaves two places side by side in each and breaks nothing. A hall of a single row reproduces neither: the party is small enough there for the whole-party move to answer, which is why this went unseen.</p> <h3>Proposed resolution</h3> <p>A judged row has the proposal's own places taken out of it, which is what a place another booking took looks like, so the remainder is judged in the row it will actually leave behind. And the remainder's flags travel with its places through the merge.</p> <h3>And the tidying afterwards</h3> <p>Folded in because it is the same booking and the same press of the same control, and because the two cannot honestly be tested apart: the arrangement this fix leaves behind is the one the tidy-up is then asked to improve.</p> <p>Consolidation took the party's length and looked for one unbroken run of it in a row, which is a run no house has for a party longer than its longest row, so it declined to try anything at all. The shape it left alone is the ordinary one: the rule on lone places makes a take stop two short of the end of a row, the next press seats those two in the row after it, and nothing afterwards puts them in the two places their own party left behind. The party stays in four pieces for the life of the order.</p> <p>It tries the pieces now. Each is asked whether the rest of the party has room beside it, and the smallest one that has moves: fewest people moved is the smallest change to a booking somebody has already been told about, and one piece fewer is the whole of the improvement being claimed. Only a move that merges, so a piece sliding along its own row without joining anything is not made. Nothing is checked about what a piece leaves behind, because giving places up can only lengthen the stretches around them. The guard the whole-party move already had carries over untouched: a party holding any place its booker chose is not tidied at all.</p> <p>What this does not do is lift the condition itself. <code>replace()</code> still asks for one unbroken run for the whole party at placement time, so a party larger than the longest row in the house still gets no whole-party move, and the piece that moves here is a repair rather than the answer. That is <a href="https://www.drupal.org/node/3620010">#3620010</a>.</p> <h3>Remaining tasks</h3> <p>A sweep, which is what would actually prove the promise. The cases below are examples, and examples found these two faults by following one reproduction rather than by auditing every rung: the same shape of fault, a rung judging against a row it is itself changing or a merge dropping a flag, could sit on a path no fixture walks. Generating small halls across row lengths, growing a party in steps and asking for every size that fits, then asserting the promise on each, either finds what is left or earns the claim.</p> <p>Worth stating what the promise is not, so the sweep asserts the right thing. An ask is still refused for reasons that are not this rule: a per-order limit, a quota, an allotment, a tariff pricing no grade that is free. And a venue that switches <code>allow_last_resort</code> off has asked to be refused rather than strand a place. What holds is narrower: the orphaned-places rule does not refuse an engine-placed ask while a legal arrangement exists, and where none exists the venue's own setting decides.</p> <h3>User interface changes</h3> <p>None. A booker who could not be seated legally is seated as the last resort it is, which is what the venue's own default asks for, and told how the party ended up sitting in the words that already exist.</p> <h3>API changes</h3> <p>None. Both changes are inside one private method and a private helper beside it.</p> <h3>Data model changes</h3> <p>None.</p> <h3>Coverage</h3> <p>The tests assert the contract rather than either fault, because the contract is what was untested. The rule's own suite covers it in isolation and every case there names the place or sets the flag by hand, which is the map, the operator and the API; nothing asked whether the ENGINE can be refused by it, and the rule's docblock says a proposal that strands a place while a legal one existed is a fault of the seating.</p> <p>So: an add the house has room for is seated; the odd one out sits where there is room for it, asserted as the arrangement rather than as a count, so that straining the rule cannot make it pass; and an add that leaves the row whole takes the places beside the party. The fixture builds several rows, since one reproduces none of it.</p> <p>AI-Generated: Yes (Claude Code found this from a reproduction it wrote, made the changes and drafted this summary. I reviewed them before posting.)</p>