Issue description:

Crashes when ticking transporter when TransitResponse.EMPTY is returned in InventoryUtils and getRejected is called without checking before if its empty

MultipartTransporter where the Responce is requested
https://github.com/aidancbrady/Mekanism/blob/1.10/src/main/java/mekanism/common/multipart/MultipartTransporter.java#L119

InventoryUtils whre an Empty Responce is returned
https://github.com/aidancbrady/Mekanism/blob/1.10/src/main/java/mekanism/common/util/InventoryUtils.java#L260

TransitResponce where the actual NPE happens
https://github.com/aidancbrady/Mekanism/blob/1.10/src/main/java/mekanism/common/content/transporter/TransitRequest.java#L151

Steps to reproduce:

Idk but the code/crashlog dosn't lie and it happens

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

**Forge:Forge 12.18.3.2316
**Mekanism:Mekanism-1.10.2-9.2.2.final (yes i know not the newest but showed it in the current code)
**Other relevant version:MCMultiPart-1.4.0-universal

If a (crash)log is relevant for this issue, link it here: (It's almost always relevant)

https://hastebin.com/aretojozic.scala

Please try with this build (or build from source) http://maven.thiakil.com/mekanism/MekanismAll-1.10.2-9.2.2.304-thiakil.jar

@thiakil im unable to test as its a server running my pack that seems be getting the crash, otherwise i would test, hopefully @ESSEM2 can test ASAP.

@thiakil could not really replicate it and the original case got fixed by replacing the pipe with a bedrock.
the code seems to work.

Notreally part of the crash but related:
Isn't it a performance leak if a pipe connected to its own chest always pump items in a loop?

I'd appreciate it if you could re-test the original crash conditions.

Isn't it a performance leak if a pipe connected to its own chest always pump items in a loop?

That's just user error, Most mods don't have any special handling for feeding to another side of the same block.

@thiakil the original case was on a server where i don't have enough permissions to modify the server so i rebuilt it in singleplayer

ok, does that setup crash with the build on curseforge?

nope

Picture of the setup (the chest is full, the bedrock is the block that caused the error)

It happens when you you got a loop with a chest and the pipes and the chest is actually full during one item got looped

I can confirm im getting reports of this issue to from a server network and im using the last mekanisn which is the final fix one

@thiakil @aidancbrady any chance a new version can be posted to curse as i really need the fix for this crash

Can you verify if it actually fixes anything?

@thiakil i can give me 10

@thiakil Ok it seems to work 99% of the time

i seem to get this in one of my test worlds https://pastebin.com/cRgXG7z6 after loading it up with version on curseforge and then it crashed and i then loaded it up with the custom version above and then i got that error each time,

but when i used the backup of the world and straight loaded the crashing world with the custom version it worked and was fine everytime of me retesting with back version

@thiakil Thanks, any eta on that release as im about to update my packs so dont know if i should wait for the build release....

Yayyyy @aidancbrady

@thiakil, check out 9.2.2.fix3 - on Curse right now :)

Great, I can poke Aidan to see if he'll release one.

That new message is known about, it was fixed on 1.11 but not backported as 1.10 is on critical-fixes-only kinda updates. I've added it to 1.10 now