fix: resolve GNU bear-off die ambiguity to the larger die#45
Merged
Conversation
A GNU bear-off step carries no die value and the matcher compares origin position only, so when both dice can bear off the same point the first ready move in roll order won. Core's must-use-larger-die rule rejects the smaller die when only one die can be played, so the robot's turn was rejected on every retry and the game froze. Production game 2d98cf14-e262-433c-baf5-95a2f878311d: one checker on the 2-point, 14 off, roll [3,5] — the matcher picked die 3. Sort ready moves by die value descending before matching. Point-to- point and reenter matching is die-unique (origin+destination determine the die), so the sort only affects the ambiguous bear-off case. Also heals pre-fix plays persisted with both moves still ready. Bump to 1.0.5.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Production game
2d98cf14-e262-433c-baf5-95a2f878311dfroze inmovingon the final play: robot with one checker on its 2-point, 14 off, roll [3,5]. GNU's bearoff hint is a single step{from: 2, to: 0}with no die value. The matcher compares bear-off steps on origin position only, so both ready moves matched and the first in roll order won — die 3. Core's must-use-larger-die rule (core PR nodots/backgammon-core#129) rejected the turn withMustUseLargerDieErroron every retry;RobotActionProcessorswallows robot-turn errors, so the game was never persisted.Reproduced locally by running
executeRobotTurnWithGNUagainst the prod game JSON — threwMust use the larger die (5) when only one die can be played; 3 was used.Fix
Sort ready moves by die value descending before matching. Point-to-point and reenter matching is die-unique (origin+destination determine the die), so the sort only affects the ambiguous bear-off case — where the larger die is always safe, and mandatory when it ends the turn. Also heals pre-fix plays persisted with both moves still ready (the stuck game heals on the next robot trigger).
Companion core fix: nodots/backgammon-core#131 (stop offering the smaller-die move at
Play.initialize).Tests
New
robot-bearoff-larger-die.test.tsreproduces the stale persisted play (both moves ready, smaller die first) with the exact GNU hint payload; asserts execution uses die 5 and the game completes. Red on main, green with the fix.