For me, it was because I was checking for empty code before the flush. Flush should be executed 'before execution', so it has to be the first thing that happens.

I posted to it's own thread in here, but rollback(2) should truncate the history beyond the rollback point. This means that by the time rollback(3) comes around, the history looks something like:
move #1
move #2
move #3
move #4
move #6

and you would rollback 3 to move #3

For anyone else that was getting stuck on the random tests, it's not tested or mentioned anywhere prior to them, but rollBack is supposed to truncate the history past the point you're rolling back to. Makes sense in hindsight :P

Worse than that, the description seems a bit lacking in this regard. Take the sample case. I went through trying to figure out the best approach to the problem, but solving the sample test on pen and paper and then in ruby, the expected answer doesn't include any distance having to do with A5, the friend in the list that doesn't have a town listed. The total is just the far sides of the triangles summed, plus the distance to the first and last town. So are we visiting every friend in the friends list, or are we only visiting towns we know the distance for, or...?

I can pass the sample tests without issue, but whenever I try to submit a solution for F#, the following error appears:
/home/codewarrior/program.fsx(25,28): error FS0039: The value, constructor, namespace or type 'Join' is not defined.

I think there may be an issue with the tests

There seems to be an issue with the standard ruby tests. [1,[1,1]] not same as [[2,2],2] is present in both the sample tests and the standard ones. I pass the sample test, but the standard one fails, on the same inputs.

There seems to be an issue with the python implementation trying to set up the validation:

File "/home/codewarrior/setup.py", line 42, in hasBulbInBetween
dx,dy = (i>x)-(i<x), (j>y)-(j<y)
TypeError: numpy boolean subtract, the - operator, is deprecated, use the bitwise_xor, the ^ operator, or the logical_xor function instead.

I realize that there's a section in the predefined tests that specifies taht this is supposed to raise an error, but whenever it's encountered in a random test, it fails with the error I've raised and stops the testing. There seems to be a problem at least with the python random tests when rollback exceeds the move history.

So, what are we supposed to do when the argument provided to rollback is greater than the length of the move history? With other illegal values, the tests would have us throw an error, but throwing an error on this is just ending the tests. Is this supposed to happen? Am I missing something?

There isn't really any information or description of what constitutes a Worker. For required documents, Foreigners are self explanitory (not Arstotzka), so are citizens of (designated) and entrants (everybody), but I can't figure out who requires a work pass. Any chance on getting some clarification?

I've been working on this thing for days, and I can't seem to pass the random tests, but there's something strange going on with the rollback procedure in the random tests? If I roll back n+1 elements in the move history, I pass the basic test, but if there's a rollback in the random test I fail it. Looking at the outputs of the board state, I can see that it seems to be expecting me to move back n elements in the history, but if I do that, I don't pass the basic test. It feels like I'm in a catch 22 here. Am I crazy, or am I missing something?

So, I know this is resolved, but how are you retrieving the commands issued during the testing? I haven't been able to figure that out looking around online, and I need to debug my code for the random testing, but I can't tell what it's doing to result in the board states not matching up.

I was able to get my passed assertions up from 40ish randoms with dijkstra to 264 random assertions with A*, but I'm still timing out solving this ridiculous number of mazes.

In the test case for (_enabled=, false), the output says it should update the key even if it's nil, which my code does. Final state of the hash at the end of an execution:
{:enabled=>false, "enabled"=>false}

So, the key is updated, but the test case still returns a mismatch on teh expected output. Looking through the comments, the issue lies in very unclear instructions indicating to update whatever key is valid. This strongly implies that you should update both, when in reality, you meant that they should be updated one or the other with the priority of the first contraint. (eg, if both are present, update just the symbol). Please update the instructions to make this clear.

The random test case generation in Ruby seems to be broken, as you can see from the incomplete values in the expected output:
Expected: [[8, [1, 2, 4, 5, 7, 9], [1, 2, 4, 5, 7, 9], [1, 2, 4, 5, 7, 9], 6, [1, 2, 4, 5, 7, 9], [1, 2, 4, 5, 7, 9], [1, 2, 4, 5, 7, 9], 3], [4, [2, 5, 6, 7, 9], [2, 5, 6, 7, 9], 8, [2, 5, 6, 7, 9], 3, [2, 5, 6, 7, 9], [2, 5, 6, 7, 9], 1], [7, [1, 3, 4, 5, 8], [1, 3, 4, 5, 8], [1, 3, 4, 5, 8], 9, [1, 3, 4, 5, 8], [1, 3, 4, 5, 8], [1, 3, 4, 5, 8], 6], [[1, 3, 4, 5, 7], 6, [1, 3, 4, 5, 7], [1, 3, 4, 5, 7], [1, 3, 4, 5, 7], [1, 3, 4, 5, 7], 9, 8, [1, 3, 4, 5, 7]], [[3, 6, 7, 8], [3, 6, 7, 8], [3, 6, 7, 8], 4, 1, 2, [3, 6, 7, 8], [3, 6, 7, 8], 5], [[1, 3, 4, 5, 6], [1, 3, 4, 5, 6], [1, 3, 4, 5, 6], [1, 3, 4, 5, 6], 8, [1, 3, 4, 5, 6], [1, 3, 4, 5, 6], 7, 2], [5, 3, [1, 2, 4, 6, 8, 9], [1, 2, 4, 6, 8, 9], 7, [1, 2, 4, 6, 8, 9], [1, 2, 4, 6, 8, 9], [1, 2, 4, 6, 8, 9], [1, 2, 4, 6, 8, 9]], [6, [3, 4, 7, 8], [3, 4, 7, 8], 1, 2, 5, [3, 4, 7, 8], [3, 4, 7, 8], [3, 4, 7, 8]], [[1, 3, 4, 5, 7], 2, 8, [1, 3, 4, 5, 7], [1, 3, 4, 5, 7], [1, 3, 4, 5, 7], [1, 3, 4, 5, 7], 6, [1, 3, 4, 5, 7]]], instead got: [[8, 5, 5, 2, 6, 7, 4, 5, 3], [4, 9, 6, 8, 5, 3, 7, 2, 1], [7, 1, 3, 5, 9, 1, 8, 4, 6], [1, 6, 5, [], 3, 7, 9, 8, 4], [3, 8, 7, 4, 1, 2, 6, 3, 5], [1, 4, 4, [], 8, 6, 1, 7, 2], [5, 3, 9, 9, 7, 8, 2, 1, 9], [6, 7, 4, 1, 2, 5, 3, 4, 8], [1, 2, 8, 3, [], 4, 5, 6, 7]]

Further, I've tested the portion of my sudoku solver, that I coded before this as an exercise, on a range of valid sudoku puzzles from a book, and the only time I would get the kind of errors in the puzzle that you see in my solution ( [] in the result) is on bad guesses when guess and check is required to solve, or an otherwise invalid puzzle. I'm pretty sure that the outputs for the expected values alone indicate an issue with the random test generation, especially if all of the inputs are supposed to be determinable and your implementation is failing on them as well.