>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3617961. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !256 >>> <p>Adding two places to a party in one ask can be refused where taking the two together breaks no rule, because the orphan rule is asked about the party plus ONE candidate place at a time rather than about the whole take. The party is then seated elsewhere, or handed back and re-placed onto the very places it was already on.</p> <p><strong>Steps to reproduce.</strong></p> <ul> <li>Attach the <code>orphaned_places</code> policy to the resource with a minimum of 2, so no gap of one may be left.</li> <li>One row of six places. A stranger holds place 6.</li> <li>A party holds places 1, 2 and 3.</li> <li>The party asks for two more places in one claim.</li> </ul> <p><strong>What happens.</strong> The party ends on places 1 to 5, which is the right arrangement, but it gets there the wrong way: every one of its bookings is deleted and re-created, and the answer says "Your places have moved so that you can sit together." although places 1, 2 and 3 never moved. Measured on the fixture above: bookings 2, 3 and 4 before the ask, bookings 5, 6, 7, 8 and 9 after it.</p> <p><strong>What should happen.</strong> The two places are taken beside the party, the three bookings already held are left alone, and nothing is announced, because nothing moved.</p> <p><strong>Why.</strong> <code>Together::extend()</code> collects the places beside the party through <code>beside()</code>, which grows the take one place at a time, and <code>nextBeside()</code> asks the orphan rule about the take so far plus the one candidate: <code>$this-&gt;orphans-&gt;allows($request-&gt;judgedRow($row), [...$taking, $place], $request-&gt;leaveAtLeast)</code>. With the party on 1 to 3 and place 6 held by a stranger, place 4 is refused because taking 4 alone would strand 5, and place 5 is never considered because it does not touch the party. So <code>beside()</code> returns nothing and <code>extend()</code> fails, although the claim asked for two and taking 4 and 5 together strands nothing. The number asked for is known to <code>beside()</code> as its limit; it is simply never given to the rule.</p> <p><strong>What follows from it.</strong></p> <ul> <li>The ask falls to the next rung. <code>replace()</code> hands back every place the party holds and takes one run, so every booking in the basket is deleted and re-created even when that run covers the places already held.</li> <li>The answer then says "Your places have moved so that you can sit together." on a claim where nobody moved, because the notice is raised on the bookings handed back rather than on the places actually given up.</li> <li>Where the party own row holds no run long enough, the party is seated in another row instead, and the two halves stay apart for the rest of the basket life.</li> <li>The places are re-shared over the run by <code>SeatingShareOut</code>, which does not try to keep each booking on the place it was already on, so tariffs move along the row as well.</li> </ul> <p><strong>Proposed fix.</strong> Judge the take as a whole. <code>beside()</code> knows how many places are being asked for, so it can collect up to that many with the preference order it uses today and ask <code>OrphanedPlaces::allows()</code> once about the finished take, shrinking by one place and asking again only if the finished take is refused. That keeps the current best-first behavior and changes only when the rule is applied. Two things worth their own tests: a party asking for two places beside it keeps its row, and a claim that moves nobody says nothing.</p> <p><strong>Also fixed here.</strong> The notice is raised on places rather than on bookings: compare the place ids handed back with the place ids taken, and say nothing when every place the party held is still held.</p> <p><strong>Found while tracing this, to be filed separately.</strong> One place the booker chose by hand disables <code>consolidate()</code> and <code>replace()</code> for the whole party, so a party split across two rows is never healed even when a run covering it is free. And <code>propose()</code> returns the answer of <code>extend()</code> without <code>overTheWholeParty()</code>, so a party split across rows is told nothing when it grows by extension, while the same party reached through any other rung is told it is not all in the same row.</p> <p>AI-Generated: Yes (Claude Code was used to help draft this issue summary and to reproduce the defect in a kernel fixture. I reviewed it before posting; there is no code on this issue yet.)</p>