RS Bridge: rs.getItem with NBT filter corrupts/locks item state in Refined Storage

[praetoras]

RS_Lock_Example.txt

Describe

Mod Versions (Running on ATM9 1.0.7):

CC: Tweaked: 1.20.1-forge-1.113.1
Refined Storage: 1.12.4

When using the Refined Storage Bridge peripheral (rsBridge), calling the rs.getItem() function with a filter table that includes a non-nil nbt key causes the corresponding item stack within the Refined Storage system to become corrupted or "locked". This prevents both interaction with the item in the RS Grid UI and causes subsequent export attempts targeting that item via the bridge to fail. Notably, though, subsequent searches for the item still succeed.

Additional Context:

• This issue was discovered while trying to fulfill MineColonies requests, where the item details (including NBT) originate from the Colony Integrator peripheral. However, the bug is reproducible with simple NBT filters like {}.
• Operations based solely on rs.listItems() and subsequent rs.exportItem() calls using the NBT data from rs.listItems() appear to work correctly (e.g., exporting excess items based on limits).
• The bug seems specifically tied to the NBT filtering logic within the rs.getItem implementation for the RS Bridge.
• Incidentally, currently the Colony Integrator returns a Java IllegalArgumentException when attempting to use the getRequests method, but Minecolonies currently has a crash associated with their clipboards, so that might be on their end. I'll submit a different bug report if that remains after ATM9 updates to the current version of Minecolonies.

Thank you for looking into this!

Steps to reproduce

1. Set up a Refined Storage system containing a stack of standard minecraft:oak_door with no NBT.
2. Connect an Advanced Computer to the RS system via the RS Bridge.
3. Run the attached test script on the computer.
4. After the script runs the rs.getItem call with the nbt key present in the filter:
   • Attempt to interact with the oak door stack within the Refined Storage Grid UI (e.g., click, drag, shift-click, etc).
   • Attempt to run an export command (I've also included in the test script that's commented out - just add an output chest somewhere and define in the script).

Expected Result:

• The rs.getItem call should successfully find the item (if present) and return its details.
• The item stack within the Refined Storage system should remain fully interactable in the RS Grid UI (can be clicked, moved, etc.).
• Subsequent rs.exportItem calls targeting this item should function correctly (assuming target inventory is valid).

Actual Result:

• The rs.getItem call successfully returns the item details, including in subsequent calls.
• However, the specific item stack matching the filter becomes "locked" or corrupted within the RS system, almost as though the bridge is attempting to 'reserve' it and not releasing it.
• In the RS Grid UI, the affected item stack cannot be clicked, dragged, or otherwise interacted with. It appears visually but is unresponsive.
• If multiple stacks of the same item exist, only the one seemingly targeted/found by the rs.getItem call becomes locked.
• Any subsequent rs.exportItem calls from the computer targeting this item fail, returning 0 items exported.
• Manually removing and re-inserting the storage disk containing the item into the Disk Drive clears the locked/corrupted state, making the item interactable again until another rs.getItem call with an NBT filter is made.
• This can also lead to item stacking issues if parts of the affected stack are manually manipulated after a disk reset.

Workaround:

The issue is completely avoided if the nbt key is either omitted from the filter table or explicitly set to nil when calling rs.getItem:

Working Filter Examples:

local filterNameOnly = { name = itemName }
-- OR
local filterNbtNil = { name = itemName, nbt = nil }

local success, result = pcall(function() return rs.getItem(filterNbtNil) end)

• Using either does NOT cause the item locking bug.
• item remains interactable, exports work fine using 'result' details

In the Video

• I show the RS inventory in its normal state, fully interactable.
• Start the 'broken' script with an nbt filter.
• Show that the GUI interaction is broken, the export is failing, and no item exported, and that the 'locked' item is getting stuck in the GUI as a separate stack.
• Upload and start the 'workaround' script
• Show the stack is still stuck.
• Reset the inventory by re-seating the RS disk.
• Show that item exports are now working and the GUI is back to normal.

Multiplayer?

Yes

Version

1.20.1-0.7.41r (Latest 1.20.1)

Minecraft, Forge and maybe other related mods versions

Minecraft: 1.20.1, Forge: 47.4.0

Screenshots or Videos

https://i.gyazo.com/d5421cd9e0ff049ed7338bc1c05522c5.mp4

Crashlog/log

No response

[SirEndii]

Hey
Are you able to test one or two older versions

[praetoras]

Hello! It might take a bit of time as I'll need to install them separately. The server I'm on is actually a friend's, but I can create test worlds using older versions. Which versions would you like me to try?

[SirEndii]

0.7.40 and 0.7.39 for now

[praetoras]

Just wanted to get back to you on this. I tried to set up a testing environment, but currently I'm getting errors when loading older versions of ATM9 that have the AP versions requested. I'm not currently able to set up a dedicated testing environment, but I can definitely run tests on the current version as needed. I may be able to try testing the older versions again later when I have more time to set up something with just those mods/versions outside of ATM9, but I wanted to give you a head's up for the time being as that may not be for a bit.