Player is removed from the EntityTracker when teleporting to unloaded chunks or changing dimensions, resulting in client side desync

Works just fine for me. Please attach a crash report, exact steps to reproduce and a video if possible.

wait, now it does work? weird
I can't see this issue now anymore, and nothing changed in my commands, world, etc

Not the first time this has been reported. Weird indeed.

should it be good to note that the first time I did a lot of teleporting to unloaded chunks?
I tried that again, had no effect the second try after it worked already

I have just ran into the same bug. I'm attaching a crash report.

I had the issue today again, as well, no idea what triggers it tho
Relogging into the world seems to fix the issue

Requesting reopening of the report

this could actually be a duplicate of MC-89361 since it works fine after relogging, and it has to do with jumping from location 1 to location 2 by the use of portals/commands

This isn't a duplicate of MC-89361 since this bug relates to status effects while MC-89361 is about commands and selectors. Speaking of which, I have a slightly more detailed description for this bug; This issue happens usually when teleporting with commands from one location to another that have a long distance between each other (Probably related to unloaded chunks), and this not only applies to speed and slowness; Also invisibility doesn't work, in spectator mode your head is seen completely untransparent, you don't take knockback from any damage, you can't hear any damage sounds, and if you had speed or slowness before the glitch happens the speed/slowness will also stay after you clear it (It won't show any particles or a tab in the GUI saying that you have the effect but your FOV is still increased/decreased and you still walk faster/slower), and I believe elytras won't work too which might be the cause of MC-90035. Dying or relogging fixes the issue.
Oh, yes, confirmed for 1.9 😛

reopened the issue, updated the description and changed report further

Thanks.

merged MC-93377, MC-98864 and MC-89994 with this one

attached files of the merged tickets

Also I don't want to look like an attention seeker or anything, but can you maybe credit me for the extra information? Because I could have also just created another issue myself and it wouldn't be considered as a duplicate (In a way). Don't have to though.

Done

Thanks.

OK, after changing a few things in my map, I found another issue and I think this is all just related to attributes since the same thing occurs with speed and slowness and they're attributes too; If you are given some armor, then teleport to unloaded chunks, when you remove the armor, your armor points stay the same, and I'm guessing if you upgrade your armor it still won't change.

@unknown, could you test it this time, I seem to be unable to reproduce in 16w15b, possibly because I set the server's render distance to 15 instead of 7.

Edit: Nvm, related to the server side render distance for me.

If it's just minigames/map/server, you can load the chunk before teleporting the player by using an end gateway. Dragnoz has a video about this which you can find here: https://www.youtube.com/watch?v=pyqzxn0e9Jw

Some of the information in this report is falsifiable. I have opened related bug MC-100911 to demonstrate a simple repro where elytra quits working, and the repro conditions are counter to the ones described in the title of this bugs.

@unknown The pre-chunk-loading suggestion does not necessarily help for a couple reasons. First, in some cases it simply does not get rid of the issue (I tested it with the repro in MC-100911) . Second, in the case of those using an end_gateway for minigames/maps, kind of the whole point of using an end_gateway rather than e.g. a pressure pad on a command block is that it is a simple command-block-free way to allow players to teleport... so needing commands as a workaround kind of defeats the benefit of using that block. This is a broad-scope bug, and I appreciate people offering suggestions that may help in certain situations, but want to be clear that this is not a general workaround.

I have to agree that it's rather hard to say what chunks are affected (in your case it's spawn chunks) for example the map I use has 2 way teleportation, but only 1 way it works (no spawn chunks on eighter side of the teleportation)

I just chose the words "unloaded chunks" as that was the case in my map, while it's "unremdered chunks" for you.

If you can find a better descriptive title please suggest it.

I'd like to add that when you are burning, you cannot see the fire. Also, in order to solve this bug, you have to kill youself and respawn.

Here are more effects of this bug:

Potion effects are displayed incorrectly. I think I ate a golden apple, went through a teleporter, and even after my absorption wore off minutes later, I still had the particle effects from it until I relogged.

Health is displayed incorrectly: I had a health-boost potion, and my extra hearts did not show after teleporting, until I re-logged.

In addition to the knockback, fire, and elytra aspects of the bug (as well as entities like painting and villagers not rendering, which I think is a different bug), I've been bitten by seven different aspect of the 'teleporter' bug in a single 1.9 CTM map!

Added to the list (but reworded a little).

Jump Boost doesn't work either. I am creating a map and when the player get teleported to unloaded chunks as soon as they join the game, they get jump boost 255, but it actually doesn't take effect. It shows up in the Inventory screen though. YOu could add this to the list.

jump boost 255

That's an unsupported amplifier, does it also not work with levels lower then 5?

I haven't tried. But what's wrong with it. Slowness 99 causes the same problem (Though you keep the effect and you can't move). Jump boost 255 makes it so you don't take fall damage. (I'm sure you know) I am not going to test it with values lower than 5 though...

That only works because the formula still functions, but mojang won't look into issues with those amplifiers, see MC-10755.

I might test it for you then, but maybe tomorrow. But wow... this bug really breaks my map. Lots of teleporting to unloaded chunks happens in it.

Related to MC-90060?

I don't think it is, that's the client receiving no chunks for a moment and thinking it falls, but get's corrected as soon as the server sends the chunks.
As for this one, it seems like a desync between the client and server, not big, but still a desync that only gets corrected upon relogging/respawning.

Oh this isn't server-side also? I thought it was, sorry.

I'm not sure, but this seems like a permanent desync that only get's fixed by relogging, while MC-90060 instantly gets corrected.

I'm not saying they are both client side, because they both are a desync, but they seem unrelated to me.

OK. But just FYI MC-90060 doesn't get corrected; it actually suffocates you.

Might relate to MC-88179

May also relate to MC-97170 and MC-97169

You can't hear any damage sounds.

The first one is already included.

Including the second one, as going trough end gateways is also teleporting.

This seems to be the endpoint of elytra not deploying so:

Only encountered this issue just now from strolling around a really hilly custom preset world. Even after about 10-20 presses of the spacebar, the elytra would not deploy, only 2-3 times have it deployed mid air after not working the first time. In creative it would be a 50/50 of just falling or going into creative_flying.

Can 'toggle' it fairly consistently between working and not working, by changing render distance between really short and really far. It feels just like how sprint can toggle back and forth randomly on servers with a lot of ping, just that this is on singleplayer.

Confirmed for 1.10.

@unknown, I think you interchanged the report numbers. "You don't take knockback from any damage." is MC-98210

Yeah, I did, thanks.

confirmed for 16w36a

Confirmed for 1.11 pre-release 1

@unknown: it has already been marked as affected for that version

I think I found what triggered this issue. For me it happened only when I teleport myself between two loadable chunk (other than the spawn).
So you can fix your map by teleporting the player to the spawn, and then to the arena.

Confirmed 1.11.2 and 17w06a

Really, REALLY strange and big bug.
On some clients it works. On some it doesn't work.
And sometimes it works normally, sometimes not. But WHEN it's bugged... RIP.
There are theories that it might have something to do with negative and positive coordinates but I don't know if that's right.
Also: teleporting from a previously unloaded chunk to the spawn chunks lets the bug occur, too. (for me, that is)

~Panossa

Confirmed for 17w18b. I lost hope.

Only at the 10th of march the cause became known. Don't lose hope just yet.

Still in pre5, but WAY less common.

With the same reproduction steps? Did this happen to you, or did you see it somewhere else? Did it have the same symptoms? Did it go away after relogging?

It goes away after dying, not sure about relogging.

It has the exact same symptoms. It has happened to me on a lan server and it has happened to a friend on a actual dedicated server while I was on. The reproduction steps are the same but it doesn't seem to work most of the time. It doesn't go away after relogging. I have pictures showing it's still not fixed in pre7 if you need them.

@@unknown what exact symptoms are you seeing since this bug caused all kind of unintended behaviors.

Both invisible and not targetable via @e confirmed in 1.12 now; forgot to test the rest

Some symptoms I saw when this bug was occuring to me:
AttributeModifiers don't work, the hat part of the skin doesn't show, elytra doesn't work, invisible to other players, and some sounds don't work. It's basically just all the symptoms that were there before.

I really don't know what triggers the bug. I tested with everything I know and didn't get it to work. So far it just seems to come at random when teleporting to unloaded chunks.

I thought this one is resolved in 1.12?

Read the comments

FVbico [Mod] FVbico (Steven Verberne) added a comment - 29/May/17 7:50 AM

Still in pre5, but WAY less common.
Permalink Edit
dinnerbone [Mojang] Dinnerbone (Nathan Adams) added a comment - 29/May/17 11:26 AM

With the same reproduction steps? Did this happen to you, or did you see it somewhere else? Did it have the same symptoms? Did it go away after relogging?
Permalink Edit
AoElite AoElite added a comment - 29/May/17 6:53 PM

It goes away after dying, not sure about relogging.

I have not been able to reproduce anymore for a couple of months, has anybody been affected recently?

This issue still exists.

We see it fairly often when a player teleports out of a chunk that gets unloaded, and then tries to sleep. Once the sleep cycle ends, the player is not able to leave their bed and must quit the game to "escape".

I believe that at some time around 1.10, a refactor changed the order of events during the tick. It appears that in earlier versions, entities received an update prior to chunks being unloaded, and now the chunks get unloaded first.

Getting the update caused updateEntityWithOptionalForce to be called, which would see that the entity was not in the chunk indicated by the entities properties. This caused the entity to be removed from the chunk, preventing it from being removed from the EntityTracker later in the tick.

Sometime after 1.7.10 a refactor appears to have inadvertently changed the order of the tick by taking what was a single method and splitting it across several subclasses. With the new order the chunks get unloaded before entities get updated, this denies the entity a chance to remove itself from the unloading chunk.

I have created a Forge mod named BedPatch that patches the Chunk.OnUnload method to look though the chunks entitylists and send a forced update to any EntityPlayers in the chunk via updateEntityWithOptionalForce prior to doing anything else. I also created a Forge PR to do the same.

I do not believe that this has to do with the check to see if the players area is loaded. I believe this is a direct result of the change in event order during the tick.

BedPatch:
https://github.com/Mordenkainen/BedPatch

Forge PR:
https://github.com/MinecraftForge/MinecraftForge/pull/4784

Have you reproduced in 1.12 or in the snapshots?

I have reproduced it in 1.10.2, 1.11.2, and 1.12.2. I have not tried to reproduce it in the snapshots yet.

It can easily be recreated by:

• Teleport a large distance from spawn (I usually do 1000+ blocks)

• Place a bed

• Teleport another 1000 blocks away

• Teleport back to the location the bed was placed.

• Sleep

When the sleep cycle ends, you will not be able to get out of bed and will have to quit the game.

Running MC through a debugger shows that this is due to the player not being in the EntityTracker.

Further debugging showed that the player was being removed from the EntityTracker when the chunk they left unloaded.

Visual comparison of the tick() methods between 1.7.10 and 1.10.2 revealed the change in event order, which was then verified via debugger.

Finally the code in BedPatch which inserts the "missing" update prior to the chunk unload prevents the issue. Users of BedPatch have also reported that they no longer have instances of not seeing other players after installing it.

As far as all the other issues reported here, I have not tried them to see if the patch resolves them, but I will try to do that tonight.

Seems to be much worse in 18w16a than in 1.12.2. Now I teleport, relog and I'm not even at the target location anymore.

EDIT: Yes, this affects 1.13-pre6. Confirmed when confirming another bug

Still an issue 1.13.1 PRE-1.

Confirmed for 1.13.1.

Can confirm for 1.13.2 PRE-1.

Can confirm for 1.13.2 PRE-2.

Can we get this resolved? It causes some pretty serious issues.

I submitted a fix for Forge and have seen no ill side effects.

At the beginning of Chunk#onChunkUnload (func_76623_d in 1.12.2, around line 187ish) add the following:

java.util.Arrays.stream(field_76645_j).forEach(multimap -> com.google.common.collect.Lists.newArrayList(multimap.func_180215_b(net.minecraft.entity.player.EntityPlayer.class)).forEach(player -> field_76637_e.func_72866_a(player, false))); // FORGE - Fix for MC-92916

This searches the list of entities in the unloading chunk for any players, and forces them to refresh their position. This causes them to be registered with the new chunk and prevents their removal from the EntityTracker.

Seems to solve all these issues.

Can we get this issue closed once and for all?

Still an issue in 1.13.2.

Can confirm for 18w43a.

Changed the reporter to @unknown.

I think I can repro this every time on 19w02a. 

1. Make a new world, in creative mode with cheats on.

2. Enter said world.

3. /tp to somewhere 1500 blocks from spawn (or fly if you want)

4. put down a bed

5. summon a cat owned by yourself (this is probably optional, but help illustrate things)

6. hopefully the cat will sit on the bed... remember where it is anyway

7. exit and save the game

8. re-enter

9. the cat will not be visible, but can be heard

10. /time set night

11. sleep in the bed

12. for me, on two different machines, and four different worlds, I now "drop" out of the bed when night is over, but cannot exit the bed interface

13. you can /kick yourself to shut down the world

Happening on my server to me and a friend 😞 neither of us can sleep anymore... is there a work around for it so we can at least sleep?

Even simpler reproduction steps: put these command in a repeating command block in the spawn chunk, or a ticking function

execute at @a[scores={Offline=1}] at @s run teleport @s ~ ~ ~
scoreboard players set @a[scores={Offline=1}] Offline 0

and create the scoreboard objective scoreboard objectives add Offline minecraft.custom:minecraft.leave_game, now every time you enter the world in any chunk but spawn chunks, you get affected by this bug.

I created a new ticket (MC-142114) to distinguish between teleporting to unloaded chunks and joining the world outside of the spawn chunks. The latter seems to be a new issue in 19w02a that results in the same desync as this ticket.

Also, as mentioned in https://bugs.mojang.com/browse/MC-142085 if you create new world, craft a bad and try to sleep on it at night - you cannot wake up either.

Hmmm..... i've been having this stupid bug for a while now too... i think this chunk desync also affects naming and tamed animals. I'm not sure if i should create another thread with this bug as it will be a dupe of this? I think??

Using a portal to go to the Nether now triggers a desync in 19w03c. Also, going to the End a second time (ie after killing the dragon and leaving) also does it.

These seems similar MC-142114, but that's been closed.

Auz, just to clairify, this issue is much older than that, and that was a direct duplicate (same issues) but different (much easier) triggering

I can no longer directly reproduce this issue as of 19w04a. There are two things that happen when I test this.

(1) MC-138114 and MC-139763. Once inside these "ghost" chunks I can 'reproduce' this issue, but it is for a limited amount of time because in most of the cases it will lead to the same crash as in (2).

(2) The server will just crash whenever I teleport a player to unloaded chunks. The crash report is 

(~~hug~~).

Single player worlds will crash without a (good) crash report.

Please review your text before sending it (if you're in "Text" mode, you can switch to "Visual" mode), because every edit sends a mail to every watcher. In total, that last comment caused 720 mails to be sent.

The desync after visiting the nether, or visiting the end for a second time is still there in 19w04a

Having the stuck in bed problem in 19w04b java single player. Bed is away from other objects. Teleporting away does not leave the bed. current workaround is to leave and reenter the game after every sleep.

Stuck in bed. 19w06a snapshot

Elytra wont deploy after changing dimensions. Overworld to Nether, doesnt deploy. Relogged and it worked again. Nether to Overworld, doesn't deploy anymore. Relog. Overworld to End. Doesnt deploy. I had it happen once in 1.13.2 as well but hasn't happened again.

Confirmed for 19w07a. 

I got the same problem that Colin McGee mentionned with elytras (on server jar version, my friends got the issue too). It seems to occurs each time you're changing dimension.

Repro steps for 19w07a:

1. start a new world, creative mode

2. place down a bed

3. /time set night

4. sleep in the bed (works)

5. make a nether portal, and use it

6. return to the overworld through portal

7. /time set night

8. sleep in the bed (works)

9. move out of the spawn chunks, et /tp 1000 ~60 1000

10. place down a bed

11. /time set night

12. sleep in the bed (works)

13. make a nether portal, and use it

14. return to the overworld

15. /time set night

16. sleep in the bed (you should now be stuck in the bed interface)

I cannot reproduce any of the above mentioned issues in 19w09a. Elytra works perfectly fine after switching dimensions, sleeping always works, no matter how far you go around the world.

I just did the exact steps from the second to last comment in 1.13.2 and could sleep. I also changed dimensions in 1.13.2 and elytra worked, same with teleporting far away. So the reproduction steps need to be updated.

I wonder if MC-144784 being fixed affected this.

Fixed in 19w09a the player is now rendered in unloaded chunks.

With which steps did you manage to reproduce it in 1.13.2 or 19w07a?

I have use the steps in the description.

Didn't work for me. 1.13.2, commands:
/effect give @p night_vision 1000 1
/tp ~ ~ ~100000
(wait a while)
/tp ~ ~ ~100000
/effect clear @p
Result: Particles go away, as expected.

Cannot reproduce this in 19w11a. If everyone agrees with me I think this should be closed as 'fixed'.

@unknown How did you even reproduce it before?

@@unknown To be honest, I cannot remember how I reproduced this in the few snapshots before I reported I could no longer reproduce this. In other words, I have probably reported incorrect behaviour in the client as a reproduction of this bug in the few snapshots leading up to 19w04a. However, I know that I was able to reproduce it the first few times (1.13.2 and < ~18w49, as mentioned by @@unknown with their code snippet) by going to extreme coordinates, but that could take more than 15 minutes to reproduce it in the way I did it (I cannot remember using on the of suggested methods and yes, I should have updated the report with my way of reproducing it, an unfortunate mistake on my end by not doing so).

If you cannot reproduce it in 1.13.2 and I have no way to prove that I was able to do so, maybe a mod can revert/purge every change since then and change the status back to fixed.

For a mod: If it is possible I would like to be disassociated with this bug report because it is causing me too much trouble in maintaining it with the amount of expertise and time that is expected from me.

Which was the last version anyone here could actually reproduce this bug and how? I would like to check if it was really fixed, but I can only do that if I know reproduction steps.

This bug shows up due to there being an old player entity object added to a chunk list. The chunk list then gets flushed along with all other entity's when the chunk is written to disk. The entity's have there entity trackers removed along with being removed from the world. Given the incorrect player object is part of a chunk that is written to disk the player tracker object gets removed as well.

This bug may show up in other instances but the main one found using nether portals due to accurate reproducibility is nether portals. Using vanilla 1.12.2 following the procedure of going from over world using a nether portal into the nether then back into over world several times and then waiting for the auto-save reproduces this bug accurately.

A global fix would be to never remove the player tracker object by removing the player object in chunk lists. This happens in World.updateEntities MCP mappings.

for (int l = 0; l < this.unloadedEntityList.size(); ++l)
{
 this.onEntityRemoved(this.unloadedEntityList.get(l));
}

This is where the flushing of player objects happens removing the player trackers along with the false player objects.

Given this bug was tested on portals the bug can easily be seen in the portal code in PlayerList.transferEntityToWorld MCP mapping names. This method is responsible for removing the player from the old dimension and placing the player in the new dimension in the correct chunk. But player is placed inside a chunk with the method call:

oldWorldIn.updateEntityWithOptionalForce(entityIn, false);

Specifically the lines:

if (!entityIn.addedToChunk || entityIn.chunkCoordX != l || entityIn.chunkCoordY != i1 || entityIn.chunkCoordZ != j1)
{
 if (entityIn.addedToChunk && this.isChunkLoaded(entityIn.chunkCoordX, entityIn.chunkCoordZ, true))
 {
 this.getChunkFromChunkCoords(entityIn.chunkCoordX, entityIn.chunkCoordZ).removeEntityAtIndex(entityIn, entityIn.chunkCoordY);
 }

 // Faster entitys can move into unloaded chunks and can get stuck in memory lagging the server. this fixes it CARPET-XCOM
 if (!CarpetSettings.unloadedEntityFix && !entityIn.setPositionNonDirty() && !this.isChunkLoaded(l, j1, true))
 {
 entityIn.addedToChunk = false;
 }
 else
 {
 this.getChunkFromChunkCoords(l, j1).addEntity(entityIn);
 }
}

This method adds the entity into the specific sub chunk list but never removes the player object. Given that the sub chunk has a lingering player object added to its list that then gets flushed along with the chunk being written to disk.

MrGrim suggested a clean fix for the specific case of the nether portals. But given there might be other instances of the player writing itself to a chunk and never having it removed then it might be prudent to make a global fix instead of individual fixes in the code.

MrGrims nether portal code fix in PlayerList.transferEntityToWorld:

/**
 * Transfers an entity from a world to another world.
 */
public void transferEntityToWorld(Entity entityIn, int lastDimension, WorldServer oldWorldIn, WorldServer toWorldIn)
{
 double d0 = entityIn.posX;
 double d1 = entityIn.posZ;
 double d2 = 8.0D;
 float f = entityIn.rotationYaw;
 oldWorldIn.profiler.startSection("moving");

 if (entityIn.dimension == -1)
 {
 d0 = MathHelper.clamp(d0 / 8.0D, toWorldIn.getWorldBorder().minX() + 16.0D, toWorldIn.getWorldBorder().maxX() - 16.0D);
 d1 = MathHelper.clamp(d1 / 8.0D, toWorldIn.getWorldBorder().minZ() + 16.0D, toWorldIn.getWorldBorder().maxZ() - 16.0D);
 entityIn.setLocationAndAngles(d0, entityIn.posY, d1, entityIn.rotationYaw, entityIn.rotationPitch);

 if (entityIn.isEntityAlive())
 {
 oldWorldIn.updateEntityWithOptionalForce(entityIn, false);
 }
 }
 else if (entityIn.dimension == 0)
 {
 d0 = MathHelper.clamp(d0 * 8.0D, toWorldIn.getWorldBorder().minX() + 16.0D, toWorldIn.getWorldBorder().maxX() - 16.0D);
 d1 = MathHelper.clamp(d1 * 8.0D, toWorldIn.getWorldBorder().minZ() + 16.0D, toWorldIn.getWorldBorder().maxZ() - 16.0D);
 entityIn.setLocationAndAngles(d0, entityIn.posY, d1, entityIn.rotationYaw, entityIn.rotationPitch);

 if (entityIn.isEntityAlive())
 {
 oldWorldIn.updateEntityWithOptionalForce(entityIn, false);
 }
 }
 else
 {
 BlockPos blockpos;

 if (lastDimension == 1)
 {
 blockpos = toWorldIn.getSpawnPoint();
 }
 else
 {
 blockpos = toWorldIn.getSpawnCoordinate();
 }

 d0 = (double)blockpos.getX();
 entityIn.posY = (double)blockpos.getY();
 d1 = (double)blockpos.getZ();
 entityIn.setLocationAndAngles(d0, entityIn.posY, d1, 90.0F, 0.0F);

 if (entityIn.isEntityAlive())
 {
 oldWorldIn.updateEntityWithOptionalForce(entityIn, false);
 }
 }

 // Players needs to be removed from chunk lists when changing dimensions. Fix for MC-92916
 if (CarpetSettings.portalTurningPlayersInvisibleFix && entityIn.addedToChunk && oldWorldIn.isChunkLoaded(entityIn.chunkCoordX, entityIn.chunkCoordZ, true)) {
 if (entityIn.addedToChunk && oldWorldIn.isChunkLoaded(entityIn.chunkCoordX, entityIn.chunkCoordZ, true)) {
 oldWorldIn.getChunkFromChunkCoords(entityIn.chunkCoordX, entityIn.chunkCoordZ).removeEntityAtIndex(entityIn, entityIn.chunkCoordY);
 }
 }
 oldWorldIn.profiler.endSection();

 if (lastDimension != 1)
 {
 oldWorldIn.profiler.startSection("placing");
 d0 = (double)MathHelper.clamp((int)d0, -29999872, 29999872);
 d1 = (double)MathHelper.clamp((int)d1, -29999872, 29999872);

 if (entityIn.isEntityAlive())
 {
 entityIn.setLocationAndAngles(d0, entityIn.posY, d1, entityIn.rotationYaw, entityIn.rotationPitch);
 toWorldIn.getDefaultTeleporter().placeInPortal(entityIn, f);
 toWorldIn.spawnEntity(entityIn);
 toWorldIn.updateEntityWithOptionalForce(entityIn, false);
 }

 oldWorldIn.profiler.endSection();
 }

 entityIn.setWorld(toWorldIn);
}

As seen in the code suggestion above the player is simply removed from the chunk it belongs to in the old world it belonged to before adding it to the new world. Given portals lack this removal the tracker object can then be deleted if the player enters the same dimension before the chunk is written to disk having an old player object in a random chunk list in the same dimension.

@unknown I just placed a repeating command block with say @r[type=player] in 1.12.2 and went through a nether portal about a hundred times. Shouldn't this stop saying my name after a while?

Hello this issue can be marked as resolved please.

Please provide reproduction steps for 1.13 or confirm the issue has been fixed

The player is still invisible for a bit of time after switching the gamemode from spectator (1.16.1)

This report is currently missing crucial information. Please take a look at the other comments to find out what we are looking for.
If you added the required information and a moderator sees your comment, they will reopen and update the report. However, if you think your update to this report has been overlooked or you want to make sure that this report is reopened, you can contact the Mojira staff in Discord or Reddit.
_{-- I am a bot. This action was performed automatically! Please report any issues in Discord or Reddit}

@@unknown, please create a new report with exact reproduction steps and if possible a video showing the bug.

still invisible for a bit

Especially the "for a bit" part sounds like it might be a separate (but possibly related) issue.

@Marcono1234 Sorry, I can't reproduce it at 1.16.2 rc-1. If I will experience this issue again, I will report it.

Doesn't seem like an issue anymore. Resolving as Cannot Reproduce.