Describe the bug

The guide says:

Also of note, the provider has to push ALL of the ingredients at once, it can't push half-batches.

However, in the case described below, this guarantee is broken.

How to reproduce the bug

1. Start with a minimal net setup: an Energy Cell, an ME Drive (with an ME Item Storage Cell), a Crafting Storage, an ME Terminal, an ME Pattern Encoding Terminal, an ME Pattern Provider.
2. Fill the net with an item of type A and an item of type B.
3. Encode a Processing Pattern: "1 item A + 1 item B = 1 item C".
4. Place this pattern into the provider.
5. Next to the provider place an inventory that can accept either items A or items B, but not items A and B at the same time (for example, a single-empty-slot inventory).
6. Request an item of type C.

The provider will push 1 item A into the inventory leaving 1 item B in itself. At this point, the ingredients have been separated breaking the atomicity guarantee. Cancelling the crafting job doesn't return any items to the net, the provider still waits to push 1 item B being unusable for other crafting jobs.

Expected behavior

ME Pattern Provider doesn't push the ingredients if it can't push all of them at once.

Additional details

In step 5, a single empty slot means that 1 item A can be pushed and 1 item B can be pushed too. So, maybe ME Pattern Provider just checks for that and doesn't account for what would happen if it tried to push A and B at the same time. If we prefill the single-slot inventory with items A (so it can only accept items A, not B) and then request an item C, than the provider will refuse to push 1 item A into the inventory (presumably seeing that it can't push 1 item B) which is the expected behavior.

Here's a real example of why recipe atomicity is crucial. Imagine a multi-block machine for fluid processing. It turns two fluids into one. It has two input valves (single-slot inventories) and one output valve. To connect the machine to our autocrafting system we create a subnet placing ME Storage Buses on the input valves and placing an ME Interface on the main net's ME Pattern Provider. Without the recipe atomicity guarantee there is a rare possibility that one fluid will be split between the two valves leaving no room for the other fluid and making everything stuck. This can often be solved by filtering which fluids can go in which valves but is very annoying.

Which minecraft version are you using?

1.21

On which mod loaders does it happen?

NeoForge

Crash log

none

The underlying transfer API in NeoForge (which has existed for many many years) does not support "atomicity", which also makes it impossible for AE2 to implement this.
NeoForge is currently working on providing transactional transfer APIs, which will make this actually possible (by allowing a rollback if not everything was able to be pushed), but for the time being: can't fix this. Especially not on 1.21.1

p.s.: I was debating whether I should leave the issue open and close it once transactional support in Minecraft 1.21.9 (planned) hits, but we're more likely to automatically implement it when we port to that version.