John Hughes

It happens even if a light block is not held & no particles are shown.

Light blocks should either break like grass stems or be stored seperately to not physically interact with the game world unless visual from holding one.

I'm going to guess the light blocks were made based off barrier blocks...

So surrounding a dirt block with light blocks and testing with nearby tnt may be nessesary.

Please also check with falling sand.

Still affects 21w14a - The Barrier and Light inner block visual particles should bypass the particle settings when held, which would then display them even on the Minimal Particles setting & instantly fix this problem.

Simple test then is supporting block a gravity affected block (Sand/Red Sand/Gravel) - if so test downwards for air/non gravity affected block.

it can propagate downwards as fast as falling sand does outwards and blocks passing the query downwards could ignore another test request for a few ticks unless moved preventing it being triggered by multiple sand* side drops.

Another reason for the optional suggestion above too, loading a chunk visualises those surface gravity blocks and caves etc not supporting them, hence the ideal time to drop them.

Edited this bug title, after watching my recording back and where it slows down, instead of just a falling column of water

it's a column of water in the middle of air blocks at the point where it slows down.

Video Of Bug Here:

https://youtu.be/Zw67F5GvAeQ

Will try to get a video clip, but have also experienced this when filling below ground gravel with air, any gravel above drops and sometimes if it's 2 blocks or more high the bottom one breaks to an item.

Bedrock is completely black (from the void side)

1.16.2 pre 1 is slower than 1.15.2 at moving pistons, the lag is similar just slower pistons on 1.16.2 pre 1

At least the [Not Responding]/Crash of 1.16.1 has gone the way of the dodo for now.

@Jeremy is it a full crash or just [Not Responding] client?
If it's the client try giving it a moment and see if it recovers, the kelp blocks breaking along with the piston movement may be causing the same update lag as my hangar door, takes about a minute to recover from [Not Responding]

Aha a version of this was caused by client side lighting updates, yes that is brilliant for lamps, I wonder if it could revert to 1.15.2 style listening to the server if more than a set quantity of pistons are triggering, this would allow smaller Redstone Circuits to carry on with lighting updates, and those moving loads of blocks (lots of pistons moving) to ignore lighting updates (preferably from any chunks with moving pistons) until the number of them moving has dropped to lower levels.

My dual sided 8x8 door works fine, even turned into a portal that has 96 pistons total, half of which pulse at the start and the other 48 as it's moving, more than that more than that and it starts lagging with the [Not Responding], Devs & Mods feel free to check the piston count in the lagging areas of my 1.16.1 test world, as listed above.

ŢThis may be the same bug affecting larger flying machines without redstone towers, not by the towers but the way they work by chaining updates forward.
See also: MC-192845

[Mojang] Panda, I have linked my test world .zip via Google Drive in the MC-192845 report along with the button co-ordinates to compare lag, sorry to mention it here but that one is still unassigned and I believe them to be the same issue, 1.15.2 thru 1.16 snapshot 4 fine but a little client lag, post snap 4 urgh client deadlock [Not Responding] I have 2 listed builds that do it, one for about 60 seconds the other to crash point.
It's bad.

Makes me wonder if they could fix this with a simple client do not recalculate light in a chunk (or 5/9) where a 0 or 1 tick piston sequence is going off, that would stop the lighting updates for those areas affected, especially as the server seems fine.

The problem is 1.16.1 will still freeze the game client for players outside of the chunks where the updates are happening.

Builds that have worked since 1.15.2 (And not 0 tick farms.) suddenly decide to lock up the game clients.

In 1.15.2 you would see the moving Redstone flying machines stuttering but the Game would still be responsive:

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

& 

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

These now put the game in a free cursor [Not Responding] state during the flying machines transition, the game starts responding after about 1 minute for the doors, but the silo build seems to just crash the game out, too long a non response I guess.

This happens in both single player and with a local server (which is happily ticking away as the game client locks up, not only has it done it to myself but to a friend connected externally too.

Have tested and the server stays running, albeit with update spikes as the flying machines move, once they stop the game clients become responsive again, however on longer delays the game not only goes [Not Responding] whilst the server ticks away it can after a few minutes crash the game client completely, even trying to login bogs down as the rapid piston updates continue.

In my experience is down to the latest client being unable to process rapid server updates as part of the 0 tick farm fixes, this however should not be the case as it's the server that should ignore rapid client updates from 0 ticks, since the 0 tick farms never moved server side (it why they never caused server lag).

The advantage I have is that I have 2 large builds, one which only lags  [Non Responsive] game client for the duration, the other causes the lag crash, and am happy for the devs to take a look for themselves!

Anyone need me to try it with hoppers and chests underneath?

I did search, it's not my fault it lists several thousand MCPE listings when searching for an MC Java bug, which in turn makes finding a duplicate near impossible, normally I wouldn't comment back to a refered issue but dang, need to ask Mojang to fix the Jira so that MCPE- & MC- listings can be ignored based on the search.

Appears to be resolved with MC-183469

It appears they are only looking for lava under air blocks, placing an upper closed trapdoor in place of an air block over lava and they suicidally pathfind through it into the lava.

As baby chickens can fit under top slabs & sideways half stairs, they may need waterlogabble blocks adding to the air listing for detecting lava/fire underneath.

as you can see from my .mp4 it happens with less lighting than specified. (20w21a)

Added 2 video clips, can offer backup of world via google drive if needed.

Please test by creating an old world, placing a user placed block then upgrading, I believe the user placed block will remain, the rest of the terrain is world seed generated, due to the changes in seed format to add biomes the original spawn seed will be different between versions accounting for your swamp to ocean change, as placed blocks are stored seperately to keep the world size down the placed block should remain in situ.

This also happens between using a 32 bit seed on bedrock and the same seed in the 64 bit java version, since the output is different.

A fix could be done by noting the limited biomes for the explored area and optimising for that limited number then allowing exploration the full extent of biomes beyond the explored area.

Or for a really old world convert whole chunks to placed blocks for format optimization, takes more storage but would keep older terrain.

A final option would be to class old explored biomes as classic biomes, overriding the new biomes when optimised.