rejected input future keeps executed listeners and runs them every idle tick

[tr330ne]

Description

INPUTS.submit hands back the shared static InputRequestFuture.rejected right away when a request with equal or higher priority is already pending, and addInputExecutedListener on it just appends to that shared list, Bot.postTick calls notifyListeners() on the current input future every tick and then resets it to rejected, so on every tick where the current future is rejected (no input request ran, or a container is open), every listener that was ever added to a rejected future runs again, nothing ever clears the list

AutoEat.startEating sets isEating = true; delay = 50 through that listener, if its right click gets rejected right away because something with equal or higher priority (11000 by default for AutoEat) is already pending in that tick, like antiafk swing, click/rotate from the terminal or a plugin, the listener sticks, from then on those ticks flip AutoEat into eating and it sends noInput + noAction for 50 ticks without checking hunger, then the next such tick starts it again. If the click is accepted first and only replaced later it gets its own future and nothing sticks. reset() on bot ticks stopping and starting clears AutoEats fields but not the listener, so the next such tick sets them again

on a live bot I saw behavior consistent with this, food at 20 the whole time while it held golden carrots (not canAlwaysEat, so hasFood was false), no use item at all, AutoEat holding the inventory manager on every action tick whenever pathing had stopped, 274 of these between 07:03:50 and 07:11:45:

[2026/09/24 07:03:50.298] [Client] [DEBUG] Starting Bot Ticks
[2026/09/24 07:03:50.317] [Client] [DEBUG] [Inventory Manager] [655385] Executing no action, requester: AutoEat
[2026/09/24 07:03:50.618] [Client] [DEBUG] [Inventory Manager] [655391] Executing no action, requester: AutoEat
[2026/09/24 07:03:50.919] [Client] [DEBUG] [Inventory Manager] [655397] Executing no action, requester: AutoEat
[2026/09/24 07:11:45.885] [Cache] [DEBUG] Player food: 19

it kept going through bot ticks stopping and starting that morning (me connecting to the proxy and leaving) and was gone after a restart. I havent captured the initial rejected startEating or reproduced the listener attachment on a test server

fix could be addInputExecutedListener skipping futures that are already completed as rejected, or a fresh rejected future per call instead of the shared one, fixing it there instead of in AutoEat would also cover the other places that do submit(...).addInputExecutedListener(...) (AutoFish, AutoOmen, KillAura, InteractWithProcess, ClickCommand) and plugins that copied the pattern

[rfresh2]

71bfe2f

[tr330ne]

71bfe2f breaks click results for every input request. InputManager.handleTick calls BOT.requestMovement(request, future) and then future.complete(true) right away, Bot.interactionTick sets the click result later in the same tick, and setClickResult now returns early because the future is already completed, so the result stays ClickResult.None

InteractWithProcess checks future.getClickResult() instanceof ClickResult.RightClickResult (and LeftClickResult) in futureSucceeded, so interactions are no longer marked successful through these click-result checks. A still-valid target can be clicked repeatedly, leaving the process pending. placement can instead terminate as failed once the item is gone. AutoFish and KillAura read getClickResult too

on a test server on pre-f027e89c, the same unload run that passed on pre-1214575f:

1. ender chest opened (window 1), clicks done, CloseContainer(1) sent, the chest gets right clicked again and the server opens window 2, the container stays open until Auto closing open container: 2 60s later and pathing is stuck while it is open
2. shulker placed, the block is in the world and gone from the inventory, but PlaceBlock logs Item: shulker_box not in inventory, stopping instead of succeeding
3. shulker opened with InteractWithBlock, the future remained pending throughout the observed run, the container is auto closed every 60s and clicked open again (windows 3, 4, 5)

[05:57:07] Sent: ServerboundContainerClosePacket(containerId=1)
[05:57:07] [Bot] Right click MAIN_HAND block at: [-1265, 100, 1306]
[05:57:07] Container 2 opened: GENERIC_9X3
[05:57:07] Received: ClientboundContainerSetContentPacket(containerId=2, stateId=1, ...)
[05:58:07] [Bot] Auto closing open container: 2
[05:58:07] [Bot] Right click MAIN_HAND block at: [-1265, 99, 1304]
[05:58:07] Received: ClientboundContainerSetSlotPacket(containerId=0, stateId=48, slot=36, item=null)
[05:58:07] [PlaceBlock] Item: shulker_box not in inventory, stopping
[05:58:07] [Bot] Right click MAIN_HAND block at: [-1265, 100, 1304]
[05:58:07] Container 3 opened: SHULKER_BOX
[05:59:08] [Bot] Auto closing open container: 3
[05:59:08] [Bot] Right click MAIN_HAND block at: [-1265, 100, 1304]
[05:59:08] Container 4 opened: SHULKER_BOX
[06:00:08] [Bot] Auto closing open container: 4
[06:00:08] Container 5 opened: SHULKER_BOX

normal request futures are already completed when Bot.interactionTick records the click result, so guarding the shared rejected sentinel instead (if (this == rejected) return;) would preserve that protection without discarding results of accepted inputs

[rfresh2]

2f33a3f