Repository navigation
Fix non-blocking jobs losing running operations on insert failure (1.20) - #255
Open
rubensworks wants to merge 1 commit into
Open
rubensworks wants to merge 1 commit into
rubensworks wants to merge 1 commit into
Conversation
When a target accepted recipe inputs in simulation but not for real, all running operations of the job were forgotten, and the refused inputs were moved to the storage network. In non-blocking mode, this made crafting jobs get stuck forever. Equal inputs are now stacked when simulating, so simulation also fails when they only fit separately. If the real insertion still fails, only that operation is undone, and the refused inputs go back to the job. Related to #252 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01D8EZpiK75euMoLjy5r6suM
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
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.
Port of #254 to 1.20. Related to the non-blocking problem described in #252 (comment).
Problem
When a target accepts the recipe inputs in simulation, but refuses part of them for real,
consumeAndInsertCraftingcalledunmarkCraftingJobProcessing. That dropped all pending output entries of the job, including operations that were already running in the machine in non-blocking mode, so their results were no longer claimed. The refused inputs were also put into the storage network instead of back into the job, leaving the job pending forever with a short buffer.Inputs are simulated one by one, so two equal instances that each fit separately are accepted in simulation while only one fits for real. This happens easily in non-blocking mode, which fills machines up to capacity.
Changes
Same as the 1.21 PR, minus the start tick bookkeeping that only exists on 1.21:
CraftingHelpers.insertCraftingoverload with a fallback storage getter; the existing signature is kept).Tests
This branch has no game tests, so the reproduction tests from the 1.21 PR are not included here. They fail without the fix and pass with it on 1.21. On this branch,
./gradlew buildpasses (172 unit tests).Generated by Claude Code