regression introduced in 62785 or 19124

[kortschak]

During the merger of materilizer into the nexter changes, I broke something. I have only just noticed while working on b/llrb changes.

62785d2 - breaking merge (expected damage)
191244c - merge resolution (introduction of failure)

The breakage shows up as a failure of the helpless checker - gives no results. It also scrambles the results of other queries but leaves their counts the same. This test is missed by travis, because we don't run long tests there, and we obviously need to implement less slipshod tests (my fault).

I'm looking into what I did now, but since it was an interaction with @barakmich's changes, it would be good it he could look as well.

cc:@barakmich

[kortschak]

Update: I'm thinking it is in the merge 62785d2 rather than the resultion of Go names 191244c. This is unfortunate since it's the much larger commit.

[kortschak]

Fixed by aad21b0.

[kortschak]

I closed too soon. I have added more stringent testing to cayley_test.go (reflect.DeepEqual on the basis that the order of returned results is consistent) and this fails. The number of results is correct though.

If I comment out the line that invokes the materializer, the test passes. The failure does not look like an out of order result return.

[kortschak]

Branch mentioned above is here.

[kortschak]

I have back ported the test case to b74cb14 and it fails there too - output here for convenience. Sorry @barakmich, I think the ball is in your court.

[kortschak]

Bisection with one skip due to panics (09244dd) points to one of these:

09244dd
24f57df

[kortschak]

I have narrowed this down to an off-by-one error. The result in the incorrect cases is returning the object of the next quad: e.g. (snipped from 30kmovies...)

 </en/speed_1994> <name> "Speed" .
 </en/speed_1994> <type> </film/film> .

 </en/keanu_reeves> <name> "Keanu Reeves" .
 </en/keanu_reeves> <type> </people/person> .

Not sure yet where it's coming from, but looking.

[kortschak]

Adding in a clone of the input iterator to the Materializer and tracking them together I see this (just running "Net and Speed"):

clone:10201 mat:10201 correct
clone:10201 mat:10201 correct
clone:10201 mat:10201 correct
clone:<nil> mat:10201 incorrect
clone:12510 mat:12510 correct
clone:12510 mat:12510 correct
clone:26153 mat:26153 correct
clone:26153 mat:26153 correct

So it looks like the off by one is due to the materializer not properly reflecting the change over in paths. If I get a chance tonight I'll keep tracking this.

[barakmich]

Fixed in #116