int range bug in Pilosa

[jaffee]

What's going wrong?

Wrong answer on range query. See steps below:

Fri 06/14 11:44:46:~()$ curl localhost:10101/index/bla -d'{}'
{"success":true}
Fri 06/14 11:48:15:~()$ curl localhost:10101/index/bla/field/aint -d'{"options": {"type": "int", "min": -9223372036854775808, "max": 9223372036854775807}}'
{"success":true}
Fri 06/14 11:48:34:~()$ curl localhost:10101/index/bla/query -d'Set(10, aint=11) Set(100, aint=15)'
{"results":[true,true]}
Fri 06/14 11:48:43:~()$ curl localhost:10101/index/bla/query -d'Row(aint > 100)'
]{"results":[{"attrs":{},"columns":[10,100]}]}

What was expected?

the two values for field aint are 11 and 15 so aint > 100 should return no columns.

Information about your environment (OS/architecture, CPU, RAM, cluster/solo, configuration, etc.)

This is happening in go-pilosa CI tests, and also on my Mac locally. 1.3.0 and v1.3.1

[jaffee]

This is only on 1.3.x – I was mistaken about master. Will edit ticket. It also only seems to happen if the range is really large (e.g. this is fine curl localhost:10101/index/blaz/field/aint3 -d'{"options": {"type": "int", "min": -4223372036854775808, "max": 4223372036854775807}}') which may actually expected. The reason it doesn't happen on master is that we have unbounded BSI, so even if you tell it to use a huge range, it won't until you actually insert integers that have that much variance.

[shaqque]

This might be related to #2015.

[jaffee]

We should probably track down exactly when this happens and put limits on the incoming range so we return an error rather than exposing bad behavior.

[jaffee]

need to validate this works properly on master and that out of range bounds are handled appropriately