Chest, Trapped Chest, Ender Chest and Barrels stop functioning when moving far away whilst in the GUI

@unknown No need for thanks, my pleasure 💙
_{(It's even easier to test with simply plopping a redstone lamp on the side of the trapped chest, but it's better to see if the GUI is still open with an elevated piston)}

After seeing MC-208051, I also tested the regular chest, enderchest, barrel, shulkerbox.

All opening animations except shulkerbox stop working also here with the mentioned method.

Leaving and rejoining fixes this issue (and of course also replacing the affected container), as also described in MC-208051.

In both methods (MC-208051 + MC-229680) the player opening the container is essentially "quickly removed".

Up to your discretion if both bugposts should be merged.
Note: I didn't test the kill-method yet, but unlike as described in MC-208051, also the enderchest's opening animation gets stuck.

I (Player 1, white) started a LAN-world in SSP, and things went a bit differently:

2nd player (blue) used the method described here, but this time the trapped chest remained visually open.

For host-player white, although it didn't open the chest, the chest remained visually closed, no animation.
For player Blue, whenever host-player white opened the chest, the chest's animation changed from open to closed, essentially the wrong way around.

If player Blue leaves the worldsave and relogs into it, the same issues as just described still persists, for both player Blue as well as White.

Only tested in SSP.

Edit: Excuses if I phrased it not clearly enough, I quickly recorded it, I think visuals are usually easier to understand 🙂
https://www.youtube.com/watch?v=A97jLQsCJfg

I tested for when this happened first time, as I found it strange if it'd have been in the game since a longer time.

Turns out it was - like noted in the affected MC versions in MC-208051 - introduced at least since 20w49a (maybe more tests needed for older snapshots?), then apparently vanished, then reappeared:

All is fine again in 1.16.5-rc1 as well as -release, but first snapshot in the launcher after that, 21w03a, this behaviour is back in the game.

Hope this will make it easier to pin down.

Can confirm in 1.17.1.

Can confirm in 21w37a

Can confirm in 21w40a

Can confirm in 1.18 Pre-release 1

Can confirm 22w17a
Also affects Chests, ender chests, and barrels. All 3 will not visually open or play opening sounds when accessed afterward. Nor will the barrel update its state

This is also the code analysis and fix for: MC-208051

Code Analysis - (Yarn 22w17a)
ViewerCountManager is used by: ender chest, chest, trapped chest, and barrel.

net.minecraft.block.entity.ViewerCountManager.java

// This gets called every tick, that's kinda sad
public void updateViewerCount(World world, BlockPos pos, BlockState state) {
	// How many viewers are there currently within 5 blocks
	int i = this.getInRangeViewerCount(world, pos);
	// How many viewers do I remember there being
	int j = this.viewerCount;
	// Has there been a change. Will return yes if a player is further then 5 blocks now
	if (j != i) {
		boolean bl = i != 0;
		boolean bl2 = j != 0;
		if (bl && !bl2) { // If new viewers and was empty before
			// Do container opening stuff like giving block updates and making sounds
			this.onContainerOpen(world, pos, state);
			world.emitGameEvent(null, GameEvent.CONTAINER_OPEN, pos);
		} else if (!bl) { // If there are no players looking at the container anymore
			// Do container closing stuff like giving block updates and making sounds
			this.onContainerClose(world, pos, state);
			world.emitGameEvent(null, GameEvent.CONTAINER_CLOSE, pos);
		}
		this.viewerCount = i; // Here we set the viewerCount to the new viewer amount
	}
	// ...
}

// Called by the player when they close the gui
public void closeContainer(PlayerEntity player, World world, BlockPos pos, BlockState state) {
	int i = this.viewerCount--; // Oh NO!
	if (this.viewerCount == 0) { // Well it was actually set to 0 before, so now its -1
		// Do container closing stuff like giving block updates and making sounds
		this.onContainerClose(world, pos, state);
		world.emitGameEvent(player, GameEvent.CONTAINER_CLOSE, pos);
	}
	this.onViewerCountUpdate(world, pos, state, i, this.viewerCount);
}

Basically the viewerCount gets to 0 above since all the players are "gone" although that's not the case and so when the player closes their gui they actually set the viewerCount to -1, causing the final closing updates not to be given.
Although that's not the only issue. Since now when the viewerCount is -1, it gets set to 0 when a player uses it, so it stays closed and will open when a second person looks into it

I'll be honest tho, I see no reason why this laggy mess of a backup system even exists. The proper solution would have been to manage your events correctly in order to prevent the inventory from staying open and instead having the distance check be done on the client. There's no need to look for blocks at EVERY single chest in the world every tick!

If you really feel like hotfixing it tho...

public void closeContainer(PlayerEntity player, World world, BlockPos pos, BlockState state) {
	int i = this.viewerCount == 0 ? 0 : this.viewerCount--;
	// ...
}

Can confirm in 1.19