Issue description:

I was in the process of setting up pre-crafting buffers of processors on a new world. I encountered a repeatable scenario where Interfaces break autocrafting.

What happens:

An Interface, when set to export items (eg: 20 silicon, but only has 1 available) will steal items that autocrafting was intending to use and autocrafing is is not prepared to replace them.

What you expected to happen:

The exporting interface should either not have been able to steal items earmarked for another crafting job, otherwise RS needs to handle replacing the item that the interface stole. As I had no crafting upgrade in the interface, I would not expect the interface to piggyback on another crafting job either.

Steps to reproduce:

1. Test world with Controller, usual grids, interface, crafter, 64k storage block. Furnace with crafter and importer, with a quartz -> silicon processing pattern.
2. pattern in crafter for cutting knive + silicon -> cut silicon. Supply Quartz, cutting knifes etc.
3. Set exporter to export 20 silicon, with NO crafting card, NO external storage loopback. System must have an overall deficit of raw silicon to demonstrate.
4. Attempt to craft 1 cut silicon.
5. Observe that the furnace crafted it, and the interface stole the silicon from the autocraft. The cut silicon crafting job is hung in "Waiting for items"

Additional step:
6. Clear the interface export slot so its silicon is returned to the storage and the crafting job will resume.

Version (make sure you are on the latest version before reporting):

• Minecraft: 1.12.2
• Forge: 14.23.4.2739
• Refined Storage: 1.6 (latest at time of report)

Does this issue occur on a server? Yes, but reproduced in SP world.

I encountered this on a real server and was instantly able to reproduce in a SP test world.

If a (crash)log is relevant for this issue, link it here:

No crash. In case the layout matters, I reproduced it in this test world https://imgur.com/a/QJeuNGj

What would you suggest as a good way to fix this?

Might wanna reschedule the task if items are missing.

Confirmed still present in 1.6.2, as expected.

The thing about this that catches my attention is that the crafting job is stuck for 'waiting for items'. That implies the crafting system never even saw the items enter the system. The state might actually be like that, but it's how I interpreted it as written.

I have been told that items earmarked for a crafting task are locked to prevent interference, but I have not seen evidence of that myself. If this is the case then what I would find least astonishing would be that the crafting system had first call on incoming items so that it could lock/reserve them before the interface could get it.

It would be unfortunate if player or interface/exporter interference caused a reschedule - that adds CPU costs.

In my mind, the Interface without the crafting card, should never be able to grab an item from autocrafting. If the items were surplus or cancelled, then sure. But interfaces should not be able to replenish their outputs as a side effect of an unrelated crafting job.

I have been told that items earmarked for a crafting task are locked to prevent interference, but I have not seen evidence of that myself. If this is the case then what I would find least astonishing would be that the crafting system had first call on incoming items so that it could lock/reserve them before the interface could get it.

They are locked during calculation for other tasks. This would solve other tasks stealing from each other, but not other blocks in RS.

There is no "marking" of items in the storage cache.

It would be unfortunate if player or interface/exporter interference caused a reschedule - that adds CPU costs.

Agreed. There must be a better solution.

I could track newly inserted items and prioritize them to go into crafting tasks first. That might solve the issue.

Newly inserted items going to crafting tasks first would be least astonishing to me.

But what if the crafting task wasn't ready for the next step as another ingredient in a multi-input recipe wasn't ready? Couldn't the item still be stolen by the other RS block while it was waiting in general storage? Or aren't intermediates using general storage this way?

AE's solution to this is dedicated storage for intermediates but that doesn't apply here.

I managed to break crafting by stealing an item via the grid.

I had a Z-Logic controller from EnderIO in progress. RS was crafting the Soularium ingots - which is painfully slow. I accidentally took one of the ingots via the grid and the crafting job hung indefinitely, waiting for the missing (aka stolen) Soularium ingot to arrive.

Maybe the right thing to do here is track the items arriving as part of a crafting job. Once it has accounted for them arriving from the previous step, and if they are no longer present when the next stage should be ready to begin, then it should recover by re-craft replacements.

To clarify, in this case, there were 4 ingots available, so it scheduled crafting of 2 more. It should have counted the two arriving and completed that step. When it discovered only 5 of the required 6 were available for the next step, it had enough information to know it needed to schedule another one.

The only real choices are to be smart about rescheduling, or to fail the job - which would be quite user hostile as effectively reporting that would be challenging. It can't silently abort with no trace.

Fixed with the new crafting system.