Chat causing subtle freezing after no activity in chat

Also seeing this occur in client version 1.17.1. It seems to have started yesterday, even though neither the server nor the client was updated.

Code analysis (yarn mapping, 1.18.1)

Packet is usually handled on the IO thread, but ClientPlayNetworkHandler#onGameMessage explicitly passes the packet to the client (render) thread. This means that all processing of the chat messages are on the render thread.

This is problematic, since MinecraftClient#shouldBlockMessages (MinecraftClient.java L2263), a method called by InGameHud#addChatMessage (InGameHud.java L1385), will call SocialInteractionsManager#isPlayerMuted (SocialInteractionsManager.java L39).

isPlayerMuted will call #isPlayerBlocked (L56) which finally calls YggdrasilUserApiService#isBlockedPlayer in authlib, which fetches the block list of Xbox if necessary.

This fetching is a blocking HTTP request, which should not be performed on the render thread. However, it apparently does, causing it to freeze.

(credit: huge thanks to IKEA on Fabricord!)

To add to apple502j, the "if necessary" part is key here. Usually the game only does this once at start of online mode. If the request fails however, it will try to fetch the list again with every chat message, unless it tried to do so less than 2 minutes ago.

That explains why not every chat message is affected (time between lag spikes is at least 2min).

It also explains how this could start happening without a minecraft update: Something changed on MS/Xbox side, and the block list requests from minecraft are failing everytime for migrated users.

I've had my server up since 23rd Dec and I've just started seeing this issue within the last 24 hours.

I've confirmed that a period of (chat) inactivity causes this, and it doesn't happen on a second message shortly after.

Edit: I'd just like to add that I'm not in agreeance of the title of this bug (subtle freeze). When this occurs in my server, it locks up everyone playing for anywhere from 0.5 to 2 seconds, which is very disruptive.

Staying inactive in the chat for over 2 minutes will reproduce this, i stand in front of smoke and after two minutes when i type you can clearly see the freeze up. 

I tried 1.18.0 and 1.18.1 with the 1.18.1 vanilla client, no mods, default profile.  no mods. 

same on spigot and paper - here's a recording of it on spigot 1.18.0 with 1.18.1 client. 

https://www.youtube.com/watch?v=XJGAgzWS8fY

What Manuel Kasten and apple502j makes sense to me.

It's not a Mojang issue if the block list is failing to be retrieved, but making the chat asynchronous would be beneficial in times where such issues occur - lag spikes in chat would still be present, but at less of an inconvenience in comparison to the entire client freezing for a second. 

It may be that older clients are experiencing the lag spikes and if so, I don't see them ever being updated with asynchronous chat so making sure this HTTP request is not taking too long, or failing, is vital for gameplay experience.

100% server side issue. My Microsoft account is unauthorized. 

Running the following command:

$ curl 'https://api.minecraftservices.com/privacy/blocklist' -H 'Authorization: Bearer ey.mySecredToken'

Results in this for a Microsoft account.

{
  "path" : "/privacy/blocklist",
  "errorType" : "UNAUTHORIZED",
  "error" : "UNAUTHORIZED"
}

For a Mojang account (not migrated), it tells you a list of your blocked users;

{
  "blockedProfiles" : [ ]
}

It should tell you a list of your blocked users for your Microsoft account as well, but Microsoft changed something server side so now we're all unauthorized. 

@Christoffer Tibell I don't that is (at least the only) cause, and it is more likely that it is a rendering problem, because for example when I use tweakeroo mod and change a setting, when the message shows up it also causes a lag spike for me sometimes (mostly when I have not used it for a while)

The cause of this issue is known. No need to post any additional comment. 😉

Can reproduce this even without third-party mods installed that try to tweak it, And it is kinda annoying in reality when this appears to be more of an vanilla issue than what older versions can produce.

As far as I can see this issue is also independent of the version. It does happen on a 1.17.1 server as well. Can the affected versions be updated?

It doesn't seem to make sense to add an older version than the current one, and that is MC-218167. This report is a clone of it.

This affects, Vanilla, Optifine, Fabric (Modded with Sodium) and Forge mod loader vanilla and optifine forge, and sodium for forge.

Thank you everyone for providing valuable information which allow us to identify where the problem originates from. We are currently looking into the root cause. Stay tuned!

Is this still an issue?
https://twitter.com/MojangStatus/status/1480495857887813638

Yes, it is. Still experiencing it

Thanks for the resolution.

This appears to be resolved for me. No longer getting any lag when chat messages are sent (by anyone, including me) after a period of not getting any. (I'd migrated to a Microsoft account too.)

[Edit] I run version 1.18.1.

Hello everyone, this issue should now be fixed. Please let us know in the comments if this is not the case. Sorry for the inconvenience!

the issue is still appearing, I have a migrated microsoft account and use 1.17.1

@FeAr try 1.18.1

No, I won't because I cant afford to convert the world on my server and to start over

Why would a bug be fixed for an old version then?

This issue was not initially caused by Minecraft but by its underlying web services that accounts depend on in order to function. This is why it should be fixed whatever game version you are currently running.

If it truly is like the comment above with explanation said, then the web services are only a workaround, this fetch should be taken off render thread in all versions affected

It's not fixed pre 1.18 because of MC-218167

@@unknown That's a completely different issue that was fixed in the latest version, and unfortunately older versions are retroactively not supported.

@@unknown This is correct, although not a workaround, just the normal behavior is that accounts fetch their information at startup. Please feel free to make another ticket in the MC project for the underlying network blocking issue.