Blocks attached to slime blocks can create ghost blocks

According to the newest duplicates the 1.9 snapshots are afffected too

For what reason?

Evidence in 1.9 pre-release 3 http://gfycat.com/FabulousHandyKite and http://gfycat.com/AdolescentSoulfulAmericanbittern

So, does this cause duplication issues with rails/carpet on multiplayer servers? Many of the "duplicate" tickets talk about duplication issues, while this ticket is just about "ghost" blocks that are client-side.

This is only related to ghost blocks, rails are a different issue.

Confirmed for 1.10, probably 1.11.

worse than ever before in 1.11.2

Related to MC-631
As you can see from the attached screenshot this is not just a visual glitch. Although the blocks cannot be mined, you can stand on them and cannot move through them. Also if standing on them in Survival mode, the player is kicked with the message "Flyng is not enabled on this server".

Here's an example in 17w06a: https://gfycat.com/BetterTemptingBubblefish

Worth noting: this wasn't an issue in 13w13a (but returned in 13w13b). Block models didn't render then (MC-114881), which would include that for 36 (the block being moved by piston block). Might indicate part of the cause.

confirmed for 1.12 sad to see that this is still not fixed

From what I am reading, this is a client-side glitch that doesn't really break anything. I have flying machines that completely get wrecked due to server-side block duping at chunk boundaries. It's ugly but the client-side ghosts are not a huge problem.

The problem here is probably related to the various other client/server communication issues that create client-side ghosts like this, server-side ghosts like when insta-mining, and problems I've more recently encountered where mining a block can take multiple tries because they just keep reappearing. The connection between client and server is TCP/IP, so I really don't understand how these messages get lost, but it seems like client/server sync really needs a serious overhaul. Since Java, console, and pocket editions are being unified (or so I hear), they will require a common protocol, and maybe it's time that this gets done correctly.

It's not so much a case of messages getting lost, as there not being a message in the first place. For... reasons... the piston motion animation is performed entirely clientside (meaning the client is told "this piston just extended", and needs to figure out what blocks are changed). (insta-mining is a different issue, but IIRC it's also a case of a block removal being rejected without telling the client)

I added a comment on MC-5694 that may be relevant to what Pokechu22 said.

However, to be clear, MC-54026 relates to client-side ghosts, blocks that appear on the client but which do not exist on the server. MC-5694 is the opposite: Blocks that exist on the server but which are not visible on the client.

suggested fix for the bug added to the Attachments. Since Client and Server can end up disagreeing about the status of the piston extensions, updating the client about the blocks left behind removes this dissynchronization.

Suggested fix in picture BzqwEv7 shows the most simple solution to fixing ghost blocks client side. It causes blinking effects that can be fixed as well. But the suggested fix fixes the ghost blocks.

@unknown, we know that the issue is three years old and that there's a dodgy fix. It's going to be fixed as soon as the developers decide to fix it (which they still decide for themselves).
Please stop commenting until you have some new and important discoveries about the issue. This is not a discussion forum. That's why your comments have been removed, not because we think it's been less than three years since the bug has been discovered.

After MrGrim pointed out the flaw of all the current suggestions he helped improve the fix for ghost blocks. A simple modification to the BlockPistonBase.java is needed to remove the ghost blocks for both server and client. The fix is to simply check the block in front of the pistons that is being grabbed. If the block in front is a moving block 36 then all sticky pistons will ignore pulling any block on the client. This is achieved by adding an extra meta data in one of the parameters on the server and send it to the client. If said meta data contains the property that it can't pull the block in front then it will ignore any pulling of blocks resulting in a perfect synchronized behaviour to how the server behaves. This fixes the ghost blocks in the most efficient and lag friendly way with minimal intrusion to the current code.

These are the 2 code suggestions that shows the changes that was made to fix ghost blocks created by pistons.
This part of the code is for the server making sure to add a meta check if the pulling blocks aren't moving
https://i.imgur.com/FmMnjKX.png
This part of the code if for the client making sure the blocks in front can't be pulled if the server doesn't pull them.
https://i.imgur.com/7mPPFoS.png

Just confirmed in 17w50a.

Also in 18w02a.

And in 18w05a.

18w07b too.

18w07c

18w08a