fix: clear a chest's lid open count when its block is replaced; make useChests await its fill commands - #4059
Open
u9g wants to merge 1 commit into
Open
fix: clear a chest's lid open count when its block is replaced; make useChests await its fill commands#4059u9g wants to merge 1 commit into
u9g wants to merge 1 commit into
Conversation
Contributor
|
Tests more than 1.5x slower than master (durations are noisy, so this is informational): |
Member
|
Approved, resolved conflict and merge |
…est(useChests): await the fill commands before opening the chest The block_actions plugin only forgets a position's open count on a closing block_action. A chest broken or replaced while open never gets one: the server drops the close block event once the block is no longer a chest. Every later open at that position then matches the stale count and chestLidMove is never emitted again. useChests hit exactly that on retry. The first attempt raced: fillChest sends three /item replace commands and opens the chest right away, but on 1.21.9+ block interaction packets run from a separate PacketProcessor queue at the start of the tick while commands wait on the main task queue, so the window snapshot arrived with only the first replace applied. The aborted attempt left the chest open, the reset's /fill removed it, and all three retries then timed out waiting for the close that chestLidMove triggers. Wait for a chat marker echo after the fill commands (extracted from the superflat reset into bot.test.awaitCommandsProcessed), and drop the open count on any blockUpdate that changes the block's name.
u9g
force-pushed
the
fix/chest-lid-stale-open-count
branch
2 times, most recently
from
September 6, 2026 17:17
e85ad0b to
60c76e9
Compare
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
2 participants
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.
Fixes the
useChestsfailure on 1.21.11 in https://github.com/PrismarineJS/mineflayer/actions/runs/34038030872/job/101499603931 (release PR #4058, which only touches the changelog).What happened
Two stacked problems, visible in the uploaded packet trace:
fillChestfires three/item replacecommands and opens the chest immediately. On 1.21.9+ block interaction packets run from the server'sPacketProcessorqueue at the start of the next tick, while chat commands wait on the main task queue and only run while the tick has time left. Under CI load the window snapshot arrived with only the first replace applied, and the mycelium assertion failed.block_actions.js. The aborted attempt left the double chest open, soopenCountByPosheld1for that position. The harness reset's/fillreplaced the chest with air, and the server drops a container's closing block event once the block is no longer a chest, so the count was never cleared. On each retry the server's open block action carried the same count,chestLidMovewas never emitted, andonce(chest, 'close')timed out three times.The second problem is a user-facing bug too: any chest broken while open never emits
chestLidMoveat that position again.Changes
lib/plugins/block_actions.js: drop the open count on ablockUpdatethat changes the block's name.test/externalTests/plugins/testCommon.js: extract the superflat reset's marker echo intobot.test.awaitCommandsProcessed(marker).test/externalTests/useChests.js:fillChestawaits that echo before the chest is opened.test/internalTest.js: regression test that opens a chest, replaces it viablock_change, and expectschestLidMoveon the next open. It times out on master and passes with the fix.Verification
useChests: passes locally on 1.21.11 and 1.8.8.standardclean.