Tencryn

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.

This occurs frequently enough that we can be certain it only started occuring within the past day. The servers performance does not decrease indicating it is 100% not a server issue. Seeing as it only just started occuring, I don't suspect it's directly related to the 1.18.1 client but a remote service, however I could be wrong about this.

The client will essentially lock up for about a second on an occasional chat message (seems when chat has been idle for a moment or is a long message).

Paper removed the patch in 1.17. Lag spikes are more likely to be more noticeable in 1.18 due to how aggressive the mountains are with the increased height limit.

Hopefully that can be fixed. I have an area in my world that is plagued by this. So many chunks don't render in certain angles. I'm using an Optifine preview for 1.16 in this image, but I can confirm that it occurs in vanilla too. It's actually weird because it isn't quite the entire chunk... you can see there is part of the wall still visible despite being in the same chunk, but that it appears as a 2D texture.

A lot of progress has definitely been made regarding this bug. It was a very confusing issue to begin with but with the help of many, we've reached a better understanding. Hopefully this all leads to an official fix. Amazing work.

I took a look at your bug report and was able to confirm that the lag spikes were being reported as light updates, and the chunks that lagged would differ depending on render distance. 

I went to my world and did some further testing to see if I could find similarities. My lag spikes aren't anywhere near as bad which resulted in slightly different logs (There were not many light updates in the logs) but I'll get to that later.

I previously reported that single player didn't experience the lag I was experiencing in multiplayer. This stands true, but also false. I was able to find chunks that lagged but they were in a very different place than in multiplayer. Odd, right?

I'm able to confirm that in the following conditions, there is a lag spike in single player between chunks 15, -19 into 16, -19: render distance set to 2, a block placed in chunk 19, 6, -19 (Lower chunks do not seem to cause lag), world spawn set to chunk 14, 4, -24. Those chunks no longer lag when the render distance is raised. Occasionally, root.gameRenderer.level.light_updates will be reported in the logs but not very often.

I tested the chunks above in multiplayer and I can confirm that the lag is very minimal. It doesn't even show up in the logs but it is present. I also tested the chunks in your world in multiplayer and the same result applied - minimal lag if any at all. There is however a lag spike in my world from chunk 7, -24 into 8, -24. In realms, the chunks will be 8, -24 into 9, -24. These chunks do not lag in single player, and are NOT affected by render distance. Again, root.gameRenderer.level.light_updates does occasionally show up but not very often.

Why are my lag spikes not as bad as in your world? I cannot confirm my assumption, but I think it's because I'm testing with one floating block as opposed to many. The block placed in the sky for me doesn't lag if placed lower BUT in your world you have created a crater. Perhaps there's a lower chunk that also causes issues? I'm not sure.

Conclusion
The chunks where lag spikes are present are different depending on if it's a multiplayer server or single player. Render distance affects single player lag spikes but not multiplayer. It seems to be related to light updates due to the occasional appearance of such in my logs and the constant appearance of such in your logs. I'm not sure why the situation differs entirely depending on whether or not it's single player. Perhaps servers take over some of the load, not sure.

I checked this out and can confirm that this occurs for me too. I also didn't know there was a log so thanks for that.

The lag spike will occur crossing -9, -4 into -8, -4 all the way up to -9, 11 into -8, 11 when render distance is set to 8. A total of 15 chunks along the Z axis.

I disagree. I haven't tested this bug in the latest update but in 1.14...

• Render distance didn't affect the lag spike and even occurred on the lowest render distance.

• It's not the lighting as it's a block placed 150 or so blocks away in the sky, and isn't even rendered in when the render distance is low.

• It is however related to the spawn chunks. It occurs when the block is placed within the spawn chunks and the player moves between certain chunks. On realms, the lag will occur when crossing the 10th and 11th chunk away from the placed block. When hosting your own server, the lag occurs between the 12th and 11th chunk away from the placed block. This inconsistency also proves that it isn't the render distance or lighting because you would expect both instances to have the same lighting.

• Because it only occurs when the block is placed in the spawn chunks, that also eliminates lighting and render distance.

Can confirm that you cannot swim normally after gliding into water in 1.14.4. Very annoying.

Can confirm that the lag occurs in vanilla 19w39a but one chunk further away than in realms (this matches up with paper, spigot and other non-vanilla servers) which is odd but no problem. For me using the server snapshot I had to move between the 12 and 11th chunk away from the placed block as opposed to 11 and 10 like on realms. Again, lag still persists without the chunk borders visible and no longer lags when the block is removed.

I'm experiencing something similar but not so extreme. Do you happen to have blocks placed 10 or more chunks away that are above Y96 in the spawn chunks? That seems to be what causes a similar stutter for me. Whether our issues are related or not, I don't know but figured I'd ask!

That may be a different issue to be honest as the lag caused by a block above Y96 will happen when render distance is set to 2 (meaning, the block isn't even close to being rendered in), and under the exact same conditions in single player it doesn't lag. In your case, it may be lighting but for me it seems to be something else.

The chunk borders are optional. The lag occurs when they aren't visible. I enabled them for the video just so we are aware that the lag occurs when crossing the chunk. 

I have found another lag spot caused by the same floating block which prompted some further investigation.

I have discovered that if you place a block at Y96 or higher within the inner spawn chunks and then travel 11 chunks away (not including the chunk the block is in) and then cross between the 11th and 10th chunk, there will be a brief lag spike. This lag spike is worsened depending on how many blocks are in the sky it seems.

I haven't tested placing the block in the outer spawn chunks. I can say that my creeper farm in my real world does cause lag which is in the outer spawn chunks but I haven't counted how many chunks away that is. I think it's 13 chunks away as opposed to 11 like with a block within the inner spawn chunks but I haven't checked to be sure. 

It does not occur if the block is placed outside of the spawn chunks.

I'm not sure why it's Y96 as the starting point - perhaps it varies on biome I'm not sure.

I'm not sure what the current status on this is but I don't think a permanent fix is strictly necessary. A game rule that prevents 0-tick farms and is enabled by default is probably the better option. That way, it all comes down to the world owners as to whether or not they want to allow 0-tick farms. This is just my opinion though - it is still an exploit regardless.