Description of the issue

Was depositing a ton of resources into my wall of drawers, had my pick in hand, and it took the pick, but never put it in the empty drawer I keep. Seems to have eaten the pick entirely, and deleted it.

Reproduction steps

1. Have drawer wall of various drawers
2. Have resources in inventory awaiting sorting
3. Double Right click on accesspoint with pick in hand
4. Pick gets deleted

Mod version

1.19.4

Operating System

Win11

Minecraft version

1.3.9

Other mods

See mod list:
https://gist.github.com/WardsParadox/bc0243b0344593a9c807169f0464986b

Server

Happens

Client

Not tested

Logs

https://gist.github.com/WardsParadox/bc0243b0344593a9c807169f0464986b

Extra Context

Logs of that time available in above gist

Creating a minimal test case would help. If you can remove some of the other mods and still reproduce the issue it would help a lot. In general, have you managed to reproduce this issue in a more controlled environment? It seems like it happened once in a survival world and the pickaxe might just have be placed into a random empty drawer somewhere.

You can use a hopper to pull out items from a access point

Seems to have been a one time issue, not been able to replicate since. Will re-open if repeatable.

I have an update on this, it seems that sometimes the entire access point gets bugged and just starts voiding everything you put in, even if there are drawers for it. It happened yesterday , i noticed my iron ingots i put in were not added so then i took some random things out and started putting them in , just 1 of a few items and none of them got added. The drawers themselves did work if i just added them directly to them. The access point got un-bugged when I broke it and replaced it. It just happened to my farming drawers too a minute ago , that's why i remembered to come write this here. Still not sure what actually causes it though, will report if i find out.

@MiloszBoghe next time it happens, run /graphlib extended_drawers:drawers debugrender start and take a screenshot of the network. I suspect something is breaking the graphlib graph and causing items to go to non-existent drawers.

If it crashes, then send logs and I'll let the graphlib dev know

Playing on 1.20.1, ate 2 of my enchanted pickaxes and an enchanted shovel, nowhere to be found. I understand this one is hard to reproduce though since some days before this i have actually stored the same pickaxes on accident before and they were just in one of the drawers, this time they are not though.

I can confirm this happens to me too on my 19.2 multiplayer world.

Should be fixed in 2.0.6

When is it coming to 19.2?

Please do, I've lost some valuble stuff this way, and I'm hesitant to play on the Minecraft server I host again until it's fixed.

When is it coming to 19.2?

I won't be backporting the full fix because it relies on newer graphlib features. I might backport a basic fix with worse performance as this is such a major bug.

On a 1.20.1 single player world, I am able to replicate this consistently by:

1. Having an access point next to any drawer in the nether
2. Placing an access point in the overworld
3. Jump into nether portal back to the nether
4. The access point in the nether starts deleting items until a drawer or access point is added or removed

Something similar seems to happen in the reverse as well as long as the overworld access point is not near spawn.

Thanks for the reproduction steps. I'll try to get this debugged and fixed as soon as possible

I've figured out the issue. It's caused by me caching the block entities in the network, but not invalidating the cache when they unload. I'll probably fix it by reworking the system to remove the cache and instead build the storage based on the graph. I'll have to do some performance testing to see if it is good enough performance wise.

Hello,

I can reproduce this constantly with  my access point. I am using Minecraft 1.20.1, Fabric loader 0.14.22 and Fabric api 0.88.1. It still happens if I disable all other mods.

It seems to always happen when the chunks get unloaded and reloaded later, e.g. when I disconnect, leave to nether or just fly far away. However, it NEVER happens when the chunks get loaded for the first time since server start.
 

In the buggy state, every item inserted into my access point gets deleted (counters of drawers do not get increased). The items still get stored if I put them into drawers directly. Also I still only can put items into the access point that are part of my drawer network (all my drawers are locked), so it seems like it still detects correctly if it would be able to store the item.

It still happens if I have empty drawers in my network that are not locked. In this state, I still can't put any new items into the access point, which should be possible, since there is a free drawer to allocate.

I can fix everything by breaking and replacing the access point.

I've also included screenshots of the graphlib debug renderer of the network in the buggy state but I can't see anything unusual/different here.

This issue is still occurring for me on v2.0.6 in 1.20.1. I have a large wall of drawers over an area of around 4 chunks, and a single access point connected to all of them, and the access point is just voiding all the items put into it. Using /graphlib extended_drawers:drawers debugrender shows all drawers connected properly and no extraneous connections either.

@LilyRose2798
I've confirmed that this is not a graphlib issue. How consistent are your issues? Do they happen on reopening the world or when you build the network?

It's a pretty consistent issue that happens almost every time you do something that causes you to quickly leave/re-enter the area. It works right after a restart, but then becomes an issue after you start leaving and revisiting the area. On my server it's most often occurring right after doing a /home somewhere else and then back, and it stays broken until I either restart the server or piece back the drawer network one chunk at a time (disconnect on all chunk boundaries, and then reconnect all the separate chunks). I've mitigated it for now by just keeping those chunks force loaded at all times, so they never get unloaded.

It's possible that one of the performance mods I'm using has a mechanic that is causing graphlib or some caching mechanism you use to not behave as it would normally. This is my custom modpack that I'm running if you want to take a look through the modlist: https://legacy.curseforge.com/minecraft/modpacks/chromaticraft-2/relations/dependencies

@edrobot the fix has been backported to 1.19.2 and 1.19.4

If it's somehow possible, I would also like to request that if a destination is not found for an item by any means (broken cache, network graph incorrect, etc), then the default behaviour would be for the item to be left in the source inventory rather than trying to be moved (i.e. only removing the item from the source inventory once it is confirmed a destination has been acquired), just so that I have confidence in using the access point without losing items, regardless of whether a bug like this comes back in the future. I'm not sure how much work this would be (I assume it would require a change to how success/failures are propagated up through the search stack), but it would be a great peace of mind if not too difficult.

Confimed: something is once again broken

If it's somehow possible, I would also like to request that if a destination is not found for an item by any means (broken cache, network graph incorrect, etc), then the default behaviour would be for the item to be left in the source inventory rather than trying to be moved (i.e. only removing the item from the source inventory once it is confirmed a destination has been acquired), just so that I have confidence in using the access point without losing items, regardless of whether a bug like this comes back in the future. I'm not sure how much work this would be (I assume it would require a change to how success/failures are propagated up through the search stack), but it would be a great peace of mind if not too difficult.

This is not really how it works. Because of how the fabric transfer api works items shouldn't get removed before they get added. The issue has been that the target is an old copy of the block entity that's no longer saved. It should be fixed now in the latest version, and I added a command for debugging.