[2.0.14] Changing Centrifuge recipe results in inputs becoming outputs

[beama]

Client: 2.0.14(Build 79988)
Server: 2.0.14 - headless

Description (What did you do?/What happened):
On copy and paste of a running set of centrifuges set to the uranium processing recipe, or when changing the processing recipe back to processing, the input raw uranium ore can become one of the outputs. Sometimes this also causes U-238 to show up under outputs twice. This also results in inserters grabbing raw uranium ore and attempting to output it. This occured on a dedicated linux server running the headless build, with three windows clients.

Expectation:
Changing the uranium recipe and setting it back to itself should result in either the centrifuge keeping the uranium input in the input spot, or dumping the raw uranium in the players inventory.

Steps to reproduce:
Unknown - we only noticed the issue when some inserters started dropping raw uranium on the output line and after fixing it were unable to reproduce. I have uploaded autosave 5 that contains an example of the issue (though well away from where my character is sitting), as well as a modified autosave 5 where my player character is standing on top of one of the affected centrifuges (in case this somehow affects reproducibility). I cannot figure out what action was taken to cause the initial issue, and the player (Top) who caused it claimed he had just copied and pasted some stuff before discovering the belt pollution.

Workaround:
Replacing the centrifuge seems to resolve the issue, as does manually emptying the centrifuge. Worst case we could always filter output to a new belt, so not a major issue by any stretch.

Attachments:
Two log files - I was unsure how often the server saved the files, so I grabbed both.
_autosave5.zip - the unmodified copy of the server autosave
autosave5_modified.zip - the modified copy where I cleaned up some graffiti and moved the character to the affected area
Odd outputs - Initial behavior
Doubled outputs - behavior after attempting to clear the oddity by resetting the recipe
Base recipe - Me sanity checking that the output isn't expected or a modified recipe

First attempt at posting a bug (as frankly I have had a bug-free experience for years, and even now am just reporting what happened 2nd-hand) so apologies if there are imperfections here.

[Hares]

That's trash slots, aren't they? This was added in 2.0 and is hardly related to the ability to control assembler behavior via circuit network.

[boskid]

Thanks for the report. I am not seeing anything that would be a bug here. If you are changing recipe remotely or by using copy-paste then machine may attempt to give you back the non matching items if the machine is in player's reach, however if player is far away the items will be moved to a dump inventory instead. Would you prefer for items to be dropped around the machine?

[beama]

Hares - We were not using circuits for these centrifuges. As far as I was able to understand, they were mostly being placed and then some minor copy/paste happened that caused the "oddity". Thank you for mentioning trash slots though, as I had not been familiar and that helped me finally test/reproduce.

Boskid - Thank you for mentioning the remote piece in particular. I was finally able to reproduce the behavior by changing a recipe from the map view. The centrifuge can't dump its outputs into the player inventory (to avoid infinite distance access cheese), and so ends up the first output provided to any inserter.

I don't think I have a strong suggestion for improvement here. Dumping to ground has its own issues that would probably be just as confusing but be harder to deal with. I think part of the confusion was that the "extra slot" looked wildly out of place because they were the same inputs/outputs as the intended recipe (though god alone knows why my user set a machine to the recipe it already was). Maybe just cordoning those off slightly with a little "trash slots" label would be enough?

Mostly I am surprised we haven't run into this before. Thank you again. Is there a way I should mark the thread as "solved" or similar, or did the move to the "not a bug" sub-topic solve this?