Skip to content

fix: op consumption check should happen in CastingVM instead of PatternIota#1035

Merged
Robotgiggle merged 1 commit intoFallingColors:mainfrom
pythonmcpi:fix_op_limit_check
May 8, 2026
Merged

fix: op consumption check should happen in CastingVM instead of PatternIota#1035
Robotgiggle merged 1 commit intoFallingColors:mainfrom
pythonmcpi:fix_op_limit_check

Conversation

@pythonmcpi
Copy link
Copy Markdown
Contributor

Currently, the op limit check happens in PatternIota.execute rather than in CastingVM. This means that executable non-pattern iota and certain continuation frames can go past the op limit, and in extreme cases, hang the server thread indefinitely. (The latter case is currently possible with addons, and the most natural fix is moving the check to CastingVM.)

This PR moves the op limit check to the same place the stack limit is checked. Player-observable behavior should remain the same.

@github-project-automation github-project-automation Bot moved this to 📋 Backlog in Hex Casting Apr 29, 2026
@Robotgiggle Robotgiggle added this pull request to the merge queue May 8, 2026
Merged via the queue into FallingColors:main with commit db47443 May 8, 2026
8 checks passed
@github-project-automation github-project-automation Bot moved this from 📋 Backlog to ✅ Done in Hex Casting May 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: ✅ Done

Development

Successfully merging this pull request may close these issues.

2 participants