Bug Description
Items will on rare occasion, visually disappear from backpack. This seems to happen at random and is determined on startup if this will actually happen. Sometimes it acts like it should. Other times, whenever the offending item is in a backpack, it will visually disappear regardless of if it was in the backpack or player inventory (or both). For me, I have found this most common with the following: (regular) golden apples, sugarcane, anvils, enchanting tables and spawners. I'm sure there's more, but those are the ones I know of thus far. As far as I can tell, the disappearing items are only from vanilla MC and not modded items. Preview will show all items as it should, though opening that inventory will make the affected items visually disappear. Attempting to sort the inventory with the items invisible has no effect, though affected items will remain invisible.

This bug has strange behavior. Seems like the game expects the slot(s) to be empty, despite there being data for items in those slots. Picking up an affected item from inside the backpack (or player inventory when backpack is also open) will have it render again, but trying to move that item with another glitched item, or anywhere else in the backpack can make it go invisible again.

I had attempted to reproduce this with just the mod, core and forge alone, but no luck. I have a massive custom modpack, so the amount of items being loaded may have partially to do with it. Although my PC is plenty beefy to run my custom pack of 415+ mods, the game seems.... not so happy.... At least as far as this issue goes.

Best I can come up with is that it may be due to some weirdness due to how many items are being loaded. Integer overload somewhere maybe? Like the game is trying to register a back-end numeric ID for the item in that slot on start-up (of the world), and for whatever reason, it gets assigned an overloaded int value? I don't know much of how modern versions of MC work, so this is just a guess. It's just weird that the game thinks that whenever the glitch happens, an item shouldn't be there so it tries to remove it, but it's never truly removed. like the item ID is a valid value, but the coremod thinks it's not and tries to remove it, or something like that.

I tried removing a mod or two, I tried testing this by itself with the core mod, nothing seemed to reliably trigger it. The only time it ever triggered was with my custom mega pack. I even tried removing my inventory sorter mod, seeing as there was another issue of something with inv sorting on a server causing issues, and nope. Not even that. Inventory sorter ends up falling back to the backpack sorting when in backpack and items never disappear from sorting.

To Reproduce
It's a toss up if this will actually happen. About 35% of all loaded sessions are likely to have items glitching like this.

1. Load world
2. Open backpack that contains one of the above listed items
3. check if item(s) went invisible.
4. If item(s) invisible, clicking affected slot will have it render again.

Expected behavior
Items don't go invisible

Screenshots

Logs
https://pastebin.com/pQt735Du (latest log)
https://pastebin.com/rKF98SWQ (debug)

Versions
Forge: 47.1.47 (also happens as far back as 47.1.3 as far as I know)
Sophisticated Backpacks: 3.18.59.909
Sophisticated Core: 0.5.89.425
And JEI version just in case: 15.2.0.27

That looks like the items have too much nbt attached to them and have overflowed the maximum size that can be synchronized to client. And as these are all synchronized in one packet it will just cut off somewhere and not synchronize the rest of the items even if those don't have any nbt.
I only see this issue occasionally with things like create contraptions and in this case it seems the culprit are the spawners that likely have a lot of nbt attached to them and potentially some other items as well. Even though this is not very common thing I may need to implement unlimited data synchronization here so that this doesn't happen anymore so I will leave this ticket open for that.

Ah so that's what it is.... Thanks for looking into it, hopefully there's a way to implement that without breaking things too much

in 1.21 neo the limit on nbt synced to client is no longer an issue so closing this as fixed from there on