When the inventory key is hit with a container window open, the client tells the server to close the container, but immediately assumes the close to have completed, and completely forgets about the container. If the server then sends a slot update for the player inventory before the close request reaches it, said update packet will be targeted at the now-closed container window, causing the client to discard it.

The attached video demonstrates this with a simulated round trip delay of 1 second.

Steps to reproduce

1. Connect to a server with high latency.
2. In front of a container block, drop an item such that it will be picked back up after the pickup delay ends, then immediately open the container.
3. Wait until immediately before the item gets picked up client-side. Trial and error is necessary to get the timing right.
4. Close the container.
5. The item pickup animation plays, but the item never appears in the client-side inventory.

Suggested fix

The simplest way to fix this would probably be to include the container state ID in the serverbound Close Container packet. The server would then compare it to its state ID for the container being closed, and resend the player inventory in full if they don't match.

I can imagine broader changes like switching to a slot numbering scheme where the player inventory wouldn't shift around depending on the open window, but realistically the above will do the trick, and is much like how things work for other kinds of inventory changes, anyway.