MaladjustedPlatypus

The use of the word "should" is with regards to someone trying to reproduce the bug, not that said behavior is what one would expect in normal gameplay. If you were to test for the bug, that is what you "should" be seeing. I'll change the word to avoid any more grammar semantics unrelated to the bug.

After further testing this seems to be a memory leak related to chunk loading. If you check the memory while standing still, not loading chunks, it should be stable. When you load chunks, whether it's via crossing portals, flying, etc. the memory use should increase and not come back down. Running farms while standing still did not affect the memory usage for us. Passive mob farms, redstone mechanisms, etc. did not contribute to the memory leak. Here's a log of our memory use up until the server crashed again.

^{Edit: Tested with a fresh world on the server, issue still persists.}

In a situation such as this where "parity" brings obvious negative consequences, why not alter Java to match Bedrock behavior instead? Allow Java raids to start during the victory celebration. Parity should seek to bring together the best elements from both codebases, not the worst.

Sorry for the duplicate comment, can't seem to add another attachment via editing existing comments. Here's a screenshot of the server directory. If anything I'm seeing more files than what is normally present so I'll back up the server files, download a fresh install and try again.

I don't think this is related to BDS-17453 since there is a permissions.json file present. Either way the server crashes are not on startup, they're after some time playing, which can vary dramatically, not sure if that's relevant to the script-watchdog setting.
Attached here is the server properties file. Not sure what would cause an issue there, thought it might be outdated since I do not see a script-watchdog setting.

Source? ^

Affects 1.6.0

Affects 1.6.0

As far as I'm aware this bug is no longer present in the latest stable release.

Can we get some explanation as to why this was marked "works as intended"? In the Discord Helen herself said that it was a bug and that rock (another dev) confirmed it as such.

That would be a separate bug, redstone powering blocks it should not be powering.

This is still occurring as of 1.2.10

Odd... Perhaps the fix was reverted from the beta? That exact test case was fixed in it (the beta).

Uploaded example screenshot. A single solid block under is enough.

This fix has broken parity with Java. Before, mobs could and should have spawned on top slabs as it was a solid flush spawning surface for them. Now, mobs no longer spawn on top slabs. A proper fix would be mobs not spawning on bottom slabs, but spawning on top slabs.

I'm noticing that this bug is not reliable. After some time the ones that always crashed no longer do and some that did not crash do.

Edit: Okay it is reliable, but has an interesting property. If you build ONE of these at a time and trigger then as you build them, you can reliably trigger the crash. However, if you build the setup, then trigger some normal non-crashing setups near it (to update the region, so to speak) the setup does not crash.

Confirmed to be fully fixed using my previous test cases.

As the 'Minecraft 12_6_2017 4_15_38 PM.png' image shows, this is fixed for certain orientations, but not all.

It can delete anything (bedrock included) and in some cases transmute pistons into various stone types

Interestingly enough the randomness itself does not seem to be intended, at least not permanently. The devs themselves have mentioned that the random order is only to prevent players growing accustomed to a broken system until they can establish a proper order method.