Factorio Forums

Sometimes inserters can pass items to each other without passing through the inventory of the entity between them.

What did you do?

I have items being passed through a requester chest by two inserters. The requester chest has trash unrequested on.

What happened?

Sometimes items are passed through the requester chest even when they should end up in the trash. The items spend no ticks in the chest and are passed directly from one inserter to the other.

What did you expect to happen instead?

Most of the time items are moved to trash and therefore not picked up by the second inserter. I expect this to happen every time.

Does it happen always, once, or sometimes?

It happens only when both inserters are in motion and they meet exactly above the requester chest. The first inserter must also have been pulling items from an inventory such as another chest at some point - though I have not worked out this condition exactly - it seems to stay in this state even if the source chest is removed.

This behaviour stands out as a bug because an inserter waiting to pick up from a chest does not exhibit this behaviour, nor does it occur if the first inserter is not in this special state triggered by being between two chests.

I have provided a save file with the inserters timed to cause this bug to occur. If you look at the 6 fast inserter to requester chests on the top right they each demonstrate differing behaviours

This looks like update order dependency. Trashing is not instant, it happens once per tick so if the inserter update order is first insert then second extract, then trashing would not happen in between. Inserter waking up on container will schedule itself before other inserter so it avoids the issue. Annoying part of this bug report is that it is about behavior that was never designed to guarantee what you are doing because it would cause extra performance penalty for checking trash conditions after every inventory interaction.

I've done a bit more testing and I think you've got it exactly right boskid.

If the inserters update in the order input-output then the item has already been picked up before the end of the tick and the trashing update doesn't see the item.

If the inserters update in the order output-input then the item spends a tick in the container/on the ground and other systems can interact with it.

How large would the performance penalty be for checking trash conditions after inventory interactions?

The inventories have to check trash condition once per tick where there has been an inventory interaction in all cases other than this specific update order. The other possibility is having to do two checks for trash conditions rather than one should two sources deposit items in the same tick.

These seem to me like edge cases that would have only a small % effect on the number of entities checking trash conditions.

Since we never guarantee the behavior you're looking for and the code is not setup to work in this manor, I'm saying this is not a bug and moving it there.

For anyone else that comes across this thread after encountering the issue, thankfully there is a workaround that is not too difficult to implement.
This setup disables the input inserter for the 1 tick where this bug could cause it to pass an item over the container without the container getting a chance to process it. This workaround is needed if you build anything that relies on the "Trash unrequested" behaviour of either requester or buffer chests.

The value of 10 is for Fast/Bulk/Stack inserters, for Long inserters use 23 and for regular use 33 (and 36 for burner if you are doing some ungodly burner inserter only run).