REPRO1

Go into a normal world, and in spawn chunks, set up these command blocks pointed in the positive Z direction, as pictured in the attachment.

RCB: testfor @p
CCCB: blockdata ~ ~ ~2 {auto:1b}
CCCB: blockdata ~ ~ ~1 {auto:0b}
ICB: say hi

The logic is: the repeating command block tests for a player, and then the conditional chain command blocks will 'pulse' the impulse command block, causing the ICB to run and continually print 'hi' to the chat. This should go on forever.

Expected: mechanism works forever.

Actual: after some arbitrary amount of time, the thing stops working. The ICB is left in the auto:1b state, which means the first CCCB will fail and the second CCCB will thus never run. The issue is that it ought to be impossible for the ICB to ever be left in the auto:1b state at the end of a tick.

This mechanism is not spanning chunk boundaries, and I can think of no 'good' explanation why this happens. I'm imagining it must be a race condition in the underlying programming, because even under 'tick lag', commands always still are supposed to always process in order (the game will slow down, but commands/logic ought not ever be broken).

REPRO2

I believe I have also seen a repro along these lines:

RCB: testfor @a {Inventory:[{id:"dirt"}]}
CCCB: setblock ~ ~ ~-2 emerald_block     // replaced redstone_block that was powrering the RCB
CCCB: tellraw @a ["Got dirt"]
CCCB: scoreboard players add Have Items 1

(This was part of a larger game, where I check for every item in the game, to see how many unique items the player obtained.)

Most of the time it worked fine. But occasionally, an item would print the message in the chat, but not increment the score on the scoreboard. That should be impossible.

This has in common with the original repro the chain of CCCBs that seems to arbitrarily stop running in the middle.

no-REPRO3

While I have managed to intentionally cause REPRO1 to happen more than once, I have not managed to reproduce it when I change the commands thusly:

RCB: testfor @p
CCCB: blockdata ~ ~ ~3 {auto:1b}
CCB: testfor @p
CCCB: blockdata ~ ~ ~1 {auto:0b}
ICB: say hi

That is, I introduced an _un_conditional command block that repeats the test, and was not able to reproduce the bug. This however is merely suggestive data, as REPRO1 is not reliable (sometimes taking many minutes to happen), so I dunno if the unconditional chain command block somehow avoids the issue, or I've just been unlucky with this alternate possible repro.

REPRO4

A repeating, followed by all conditional chains:

testfor @p
scoreboard players add @p Score 1
scoreboard players add @p Score 2
scoreboard players add @p Score 4
scoreboard players remove @p Score 7

Expected: Your score should stay zero for all time.

Actual: after a few minutes, my score became 1, and stayed 1 when I broke the redstone_block I'd used to power the repeating_command_block. This is pretty demonstrative that during one iteration, the add-two-CCCB failed despite its booty-block-predecessor succeeding.

REPRO5

Similar to repro4, but with one unconditional

testfor @p
scoreboard players add @p Score 1
testfor @p                                     // unconditional chain
scoreboard players add @p Score 2
scoreboard players add @p Score 4
scoreboard players remove @p Score 7

Expected: Your score should stay zero for all time.

Actual: I went AFK, and upon my return a few minutes later, my score was... 16! (and stayed 16 when I broke the redstone_block I'd used to power the repeating_command_block). This is pretty demonstrative that during multiple iterations, some of the CCCB failed despite their booty-block-predecessors succeeding. I'll attempt to record video on this repro to notice exactly which scores I get in the interim.

Aha, got the video, this time the final score was 8, but it was 0 for about 10 mins, then went to 1 for a few seconds, then went to 8. I believe that adds new information. It suggest that the add-2 failed to fire on some iteration, and the remove-7 failed to fire on a later iteration. The add-2 is noteworthy because one of my prior hypotheses was that the only failures that happen were CCCBs preceded by other CCCBs. But now we have evidence of a CCCB that failed to run after a (presumably) successful UCCB (the testfor @p).

Also saw it go 0...3...10...13. I'm finding it's much easier to reproduce under load, e.g. I can make a repeating command block do "/tp @p ~ ~ ~1" (be sure to know the coords to turn it off) so that I can be running the terrain generator, and it reproduces more quickly. So perhaps this is somehow related to entity-processing ticks the server sometimes discards when it falls behind? Dunno.

REPRO6

Another breakthrough; conditional blocks are not required at all. Repeating followed by _un_conditional chains:

testfor @p
scoreboard players add @p Score 1
scoreboard players add @p Score 2
scoreboard players add @p Score 4
scoreboard players remove @p Score 7

After a short time, my score became 1. This chain is not bridging a chunk boundary; it's all in one section.

I actually posted a video showing repro6 (my score ended up '3'), and someone pointed out that the scoreboard actually flashed 0...3..0..3... that is, went to 3, then back to 0, then immediately back to 3 and stayed there.

I vaguely recall a long while back (months ago) that I saw the scoreboard sidebar sometimes appearing to update 'mid tick'. I don't know that I've seen that recently, but in that video clip, it suggests that possible the scoreboard displayed the score mid-tick, and the next tick (or something very soon after) was the one that failed. This may or may not have any relation/bearing on the actual implementation of the bug, but I figure 'the more info, the better'.