Query Engine unit test failures

[otoolep]

Seeing these occasionally on Travis only. Looks query engine related.

--- FAIL: TestServer_RawDataReturnsInOrder (5.34s)
    server_test.go:1716: unexpected row(0) during COUNT: {"series":[{"name":"cpu","columns":["time","count"],"values":[["1970-01-01T00:00:00Z",421]]}]}
=== RUN TestServer_LimitAndOffset
--- PASS: TestServer_LimitAndOffset (0.69s)
=== RUN TestServer_ExecuteWildcardQuery
--- FAIL: TestServer_ExecuteWildcardQuery (0.46s)
    server_test.go:1816: expected                            {"series":[{"name":"cpu","columns":["time","val-x","value"],"values":[["2000-01-01T00:00:00Z",null,10],["2000-01-01T00:00:10Z",20,null],["2000-01-01T00:00:20Z",40,30]]}]}
    server_test.go:1817: unexpected results during SELECT *: {"series":[{"name":"cpu","columns":["time","val-x","value"],"values":[["2000-01-01T00:00:00Z",null,10],["2000-01-01T00:00:10Z",20,null]]}]}

[otoolep]

@pauldix

[corylanou]

Hmm, that second one should of been fixed with this #1942.

[otoolep]

Unfortunately it does not appear to have been. These test failures are from moments ago.

https://travis-ci.org/influxdb/influxdb/builds/54491855

[corylanou]

Is the failure on master or on a branch?

[corylanou]

Ok, got it to fail finally (put it on a tight loop). This appears to be not a case of sort order, but a case of us out-running the writes with the query.

[corylanou]

@benbjohnson you might want to take a look at this one. Sync is returning true with the index being there, but the data is not queryable yet. Is this a result of the changes to index per topic?

[toddboom]

@corylanou I'm going to assume that it's probably less likely to appear in the wild than in a test. Unless you think it's unwise, I'll cut RC12 without this being fixed.

[corylanou]

I think we are fine to cut the RC. If I understand the issue properly, for this test specifically, we can't trust the "sync" method. Because we are writing two different series, I thin we can have two different topics. Index is not always in order when it is applied, but index per topic is. I think this is a situation where a higher index from a different topic was applied, and the Sync method returns true (stops blocking) and the test continues. We'll likely have to take the same approach in our server tests that we did in our integration tests, which is creating a query and wait/timeout methodology, and that will get rid of these race conditions.

In short, yes, feels like a testing issue, not a bug.