Requester does not reschedule crafts if results do not enter the same network

[drink1101]

Minecraft Version

1.20.1

Mod Version

1.1.5

Describe the bug!

if the requested item or fluid is used toooo fast, the requester can't react and just do nothing even there's no requested item in ae until you re request it.

Crash Report

No response

Log

No response

Additions and Modifications

Yes

Additions and Modifications Description

No response

Did the issue happen in singleplayer or on a server?

Singleplayer

[rlnt]

I have no idea what this means. Could you elaborate and give more context? I need a reproduction setup. What does it mean when you say an item or fluid is too fast?

[rlnt]

Closing due to no response.

[Zarkov2]

I think I'm seeing this behavior, also in mod version 1.1.5 (Star Technology ETA 3 Hotfix 2).

If the output of a fluid craft that was requested by the Requester immediately is removed from the network, e.g. there is a storage bus moving it to another network, the Requester will (eventually?) enter an idle state for that recipe and not perform further crafts even though there is no fluid of that type left in the network.

Not sure if a server restart will cause the requester to reschedule the craft. Manually changing the requested stock amount down and back up causes the craft to be performed again, but only a limited number of times (possibly once).

Setup to reproduce: Fusion MK3 reactor crafting neutronium using a pattern provider where the created neutronium is stored to another network using a storage bus. The reactor also crafts the needed lutetium and americium using patterns. Other input liquids are available to the network via a separate storage bus.

[Celivalg]

do you pipe the output of the fusion reactor through an interface on the network where the requester is present?

context: AE2 autocrafting requires an "Item entering system" event as per their documentation, which doesn't happen if you put the crafting result behind a storage bus without going through the network

[Zarkov2]

@Celivalg Yes, the reactor's output hatch (only one not locked to water) faces an interface that is on the same network as the requester.

Since the requester goes from crafting to idle state for the recipe after it's completed, it seems to successfully detect that the craft no longer is running. If there also is an output amount check, could it simply be removed?

The issue can also be seen if a fluid is crafted and then present in the same network as the requester for a short time. Example being keeping 1 bucket of uranium hexafluoride in stock, that also is exported to a machine using an interface. If 1 or 2 buckets are kept in stock, the requester will frequently but not always get stuck in idle mode. But with 10 buckets stocked it doesn't seem to happen, or only rarely.