Describe the bug

Have a pattern provider connected to some Gregtech machine via a subnet in the usual way. This pattern provider will ignore items already inside the machine and push ingredients despite being in blocking mode. (This does not happen when the machine is directly on the pattern provider).

How to reproduce the bug

Mods present:

• AE2 (version 15.4.6)
• Gregtech Modern (version 7.0.1)
• GuideME (version 20.1.11)

Set up a main net and a subnet like so:

On the main net are a pattern provider, creative energy cell, drive (containing a creative item cell), pattern encoding terminal, and a 256k crating storage. On the subnet are an interface and a storage bus that is connected to an Advanced Assembler from Gregtech (the front face should not be opposite the storage bus). Replacing the Advanced Assembler with an LV Input Bus (facing any direction) also reproduces this issue.

Set the pattern provider to blocking, then start any crafting job that uses that pattern provider multiple times. The crafting job will push as many items to the machine as it possibly can, without waiting for the ingredients that were already pusehd to disappear.

Further details

The pattern used in this example:

The configuration of the creative item cell in the drive:

The situation resulting from queueing the pattern 16 times:

Expected behavior

The pattern provider should wait for the pushed ingredients in the machine to disappear before attempting to push new ingredients.

Additional details

No response

Which minecraft version are you using?

1.20

On which mod loaders does it happen?

Forge

Crash log

https://gist.github.com/zbrachinara/2091e954f233a2205f147fae7c3401ee

Afaik the pattern provider only checks the inventory of its direct neighbor (i.e. the interface), not the entire subnet. If the interface is empty the blocking mode pushes the next batch. If you attach the advanced assembler directly, the pattern provider will check the advanced assembler which is not yet empty.
Why do you need a subnet in this particular setup though if you only attach one storage bus anyway?

If you replace the machine with a chest, the pattern provider behaves as described in the docs:

Pattern providers have a special interaction with interfaces on subnets: if the interface is unmodified (nothing in the request slots) the provider will skip the interface entirely and push directly to that subnet's storage, skipping the interface and not filling it with recipe batches, and more importantly, not inserting the next batch until there's space in the machine.

And the reason that you would want this behavior, for example, is to have early game parallelization, or direct multiple pattern providers to one machine. I only have one of each here for minimum reproduction.

Sorry wait, there's a sentence afterwards I forgot to include from the docs:

This works correctly with blocking mode, the provider will monitor the slots in the machine for ingredients, instead of the slots in the interface.

Turning on "report inaccessible items" in the storage bus should fix this.
(this may not work for all machine, but it should for all machines that works with just the pattern provider)

In general, blocking mode (directly or using a subnet, it doesn't really matter in this case) only works if the block you are pushing into actually exposes its contents.
An easy way to check if it does that, is putting a terminal on the subnet. If you can see the items, so can the pattern provider.

Wow that works, thanks. I've never had report inaccessible items have a legitimate use like that before. This fixes the issue for me.