Skip to content

Stop reporting invalid inputs for jobs that only wait for their interface (1.20) - #247

Merged
rubensworks merged 2 commits into
master-1.20-ltsfrom
fix/stale-invalid-inputs-1.20
Oct 12, 2026
Merged

rubensworks merged 2 commits into
master-1.20-ltsfrom
fix/stale-invalid-inputs-1.20

Conversation

@rubensworks

@rubensworks rubensworks commented Oct 12, 2026 •

Copy link
Copy Markdown
Member

Backport of #246 to 1.20.

Problem

If a crafting interface's target refuses a job's inputs, the job is marked as having invalid inputs. That happens for example when a furnace is still smelting something else. Pending jobs are only tested again while the interface has room to start a job. So once another job starts, the refused jobs keep reporting INVALID_INPUTS until that job is done, even though they are only waiting for the interface. Terminals show this as a failed "Recipe Not Allowed" job. Crafting itself completes correctly.

Fix

Once CraftingJobHandler has inserted a started job into the target, it clears the mark on that handler's other pending jobs, the same change as #246.

  • If the target refuses the inputs on the real insertion, the other jobs keep their mark.
  • Cleared jobs are tested again on the next attempt, so a target that keeps refusing is still reported.

Testing

🤖 Generated with Claude Code

https://claude.ai/code/session_01C5iUzweRYoCkKB5bvJdH8Y

…face

When the target of a crafting interface refused a job's inputs, for example a
furnace that was still busy, the job was marked as having invalid inputs. Jobs
are only tested again when the interface has room to start one, so once another
job started, the refused jobs kept that mark until the running job was done,
even if the target had accepted inputs again in the meantime. Terminals showed
them as failed for that whole time.

Starting a job now clears the mark on the other pending jobs of the same
interface, as their earlier test no longer applies. They are tested again on
the next attempt, so a target that keeps refusing is still reported.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01C5iUzweRYoCkKB5bvJdH8Y
If the target refused the inputs on insertion after all, its state did not
change, so the other jobs keep their mark.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01C5iUzweRYoCkKB5bvJdH8Y

Copy link
Copy Markdown
Member Author

The failing coverage/coveralls status (-0.04%) is the 8 new lines in CraftingJobHandler.update not being run by any test on this branch. The Build check passes.

  • 1.20 has no game tests, and there are no unit tests for CraftingJobHandler.update. Covering it would need a mocked network, crafting interface and target, which is out of proportion for this change, so I'm not adding a test here.
  • The same change is covered by the game test in Stop reporting invalid inputs for jobs that only wait for their interface #246 on 1.21, where coverage went up (+0.3%).

Generated by Claude Code

@rubensworks
rubensworks merged commit ac3ffcd into master-1.20-lts Oct 12, 2026
3 of 5 checks passed
@rubensworks
rubensworks deleted the fix/stale-invalid-inputs-1.20 branch October 12, 2026 17:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants