Dark color may actually be intended (inherits default gray color in this spot) but the missing render is surely not
I wrote a patch that seems to help with the remaining issue while the chests are open
Index: net/minecraft/world/entity/ai/behavior/TransportItemsBetweenContainers.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/net/minecraft/world/entity/ai/behavior/TransportItemsBetweenContainers.java b/net/minecraft/world/entity/ai/behavior/TransportItemsBetweenContainers.java
--- a/net/minecraft/world/entity/ai/behavior/TransportItemsBetweenContainers.java (revision 9ceed0392b1bed23ac562ba56adc889d3d60315a)
+++ b/net/minecraft/world/entity/ai/behavior/TransportItemsBetweenContainers.java (date 1758315147845)
@@ -62,6 +62,7 @@
@Nullable
private TransportItemsBetweenContainers.ContainerInteractionState interactionState;
private int ticksSinceReachingTarget;
+ @Nullable private net.minecraft.world.level.pathfinder.Path interactionPath;
public TransportItemsBetweenContainers(
float speedModifier,
@@ -213,6 +214,7 @@
}
private void startOnReachedTargetInteraction(TransportItemsBetweenContainers.TransportItemTarget target, PathfinderMob mob) {
+ this.interactionPath = mob.getNavigation().getPath();
this.doReachedTargetInteraction(
mob,
target.container,
@@ -225,6 +227,7 @@
}
private void onStartTravelling(PathfinderMob mob) {
+ this.interactionPath = null;
this.onStartTravelling.accept(mob);
this.setTransportingState(TransportItemsBetweenContainers.TransportItemState.TRAVELLING);
this.interactionState = null;
@@ -333,7 +336,9 @@
return true;
}
- Path path = mob.getNavigation().getPath() == null ? mob.getNavigation().createPath(this.target.pos, 0) : mob.getNavigation().getPath();
+ Path path = mob.getNavigation().getPath();
+ if (path == null && this.state.equals(net.minecraft.world.entity.ai.behavior.TransportItemsBetweenContainers.TransportItemState.INTERACTING)) path = this.interactionPath;
+ if (path == null) path = mob.getNavigation().createPath(this.target.pos, 0);
Vec3 positionToReachTargetFrom = this.getPositionToReachTargetFrom(path, mob);
boolean isWithinTargetDistance = this.isWithinTargetDistance(getInteractionRange(mob), this.target, level, mob, positionToReachTargetFrom);
boolean flag1 = path == null && !isWithinTargetDistance;
I've generated and attached a world as requested: https://www.mediafire.com/file/l1jvhcj9w2g92o2/world.zip/file (uploaded to fileshare site as it is 100mb), but it should be noted that there is nothing special whatsoever about this world - it is a standard 1.17.1 world generated from a random seed. The issue is reproducible using any 1.17.1 (and possibly prior) world, using my specific world is not needed.
As far as whether this happens in a Windows environment, I haven't tested it myself as I don't normally use Windows, but I don't think any part of this issue is platform-specific, I would expect the same results across macOS, Linux, BSD, Windows, etc.
I don't think MC-243471 is the same issue. That report details memory usage exceeding the allocated amount, which doesn't happen in the case of this issue, where the heap fills up to the allocated size, and then the server crashes. This issue also does not entail a system wide freeze like the other issue does, and is happening for the vanilla overworld dimension, contrary to the comment from yitzy299 on the other issue.
Can confirm that yes, this does still happen in 1.16.2. The fix mentioned by Insane96MCP works perfectly (moving the call to update the boss bar outside the if/else block). I recently fixed this bug in Paper with the following patch file (2 line diff): https://github.com/PaperMC/Paper/commit/c8542f236568b6e168f59d79b02d62d3fb11f690
White color does ‘fix’ that part