Panic on derivative() query

[dahankzter]

Server dies with panic:

panic: interface conversion: interface is int64, not float64

goroutine 31 [running]:
github.com/influxdb/influxdb/influxql.func·021(0xc2080c8800, 0x1, 0x1, 0x0, 0x0)
/root/.gvm/pkgsets/go1.4.2/global/src/github.com/influxdb/influxdb/influxql/functions.go:1061 +0x2ea
github.com/influxdb/influxdb/influxql.(_MapReduceJob).processAggregate(0xc2080fee00, 0xc2080fa180, 0xc2080c87f0, 0xc208144000, 0x5a1, 0x5a1, 0x0, 0x0)
/root/.gvm/pkgsets/go1.4.2/global/src/github.com/influxdb/influxdb/influxql/engine.go:784 +0x33d
github.com/influxdb/influxdb/influxql.(_MapReduceJob).Execute(0xc2080fee00, 0xc208125ce0, 0x0)
/root/.gvm/pkgsets/go1.4.2/global/src/github.com/influxdb/influxdb/influxql/engine.go:170 +0x8ca
github.com/influxdb/influxdb/influxql.(_Executor).execute(0xc208072380, 0xc208125ce0)
/root/.gvm/pkgsets/go1.4.2/global/src/github.com/influxdb/influxdb/influxql/engine.go:926 +0xba
created by github.com/influxdb/influxdb/influxql.(_Executor).Execute
/root/.gvm/pkgsets/go1.4.2/global/src/github.com/influxdb/influxdb/influxql/engine.go:905 +0x5a

[jwilder]

Looks like this may have been fixed via #2917

[dahankzter]

Will there be builds for RHEL regularly? I can build by hand but I prefer the package manager and soon I will no longer manage our installs and I prefer our ops dealing with rpm's rather than building from source even if Go makes it very easy.

[dahankzter]

No the latest master does not seem to fix it. A simple "select derivative(value) from theData" still gives:

panic: interface conversion: interface is int64, not float64

goroutine 116 [running]:
github.com/influxdb/influxdb/influxql.(_MapReduceJob).processRawQueryDerivative(0xc2081071f0, 0xc2083ff800, 0xc208482000, 0xd4, 0x100, 0x0, 0x0, 0x0)
/home/henrik/dev/src/github.com/influxdb/influxdb/influxql/engine.go:411 +0x2ff
github.com/influxdb/influxdb/influxql.(_MapReduceJob).processRawQuery(0xc2081071f0, 0xc2080d3aa0, 0x0)
/home/henrik/dev/src/github.com/influxdb/influxdb/influxql/engine.go:353 +0x9f2
github.com/influxdb/influxdb/influxql.(_MapReduceJob).Execute(0xc2081071f0, 0xc2080d3aa0, 0xc20814b700)
/home/henrik/dev/src/github.com/influxdb/influxdb/influxql/engine.go:81 +0x11ec
github.com/influxdb/influxdb/influxql.(_Executor).execute(0xc208127300, 0xc2080d3aa0)
/home/henrik/dev/src/github.com/influxdb/influxdb/influxql/engine.go:926 +0xba
created by github.com/influxdb/influxdb/influxql.(*Executor).Execute
/home/henrik/dev/src/github.com/influxdb/influxdb/influxql/engine.go:905 +0x5a

[dahankzter]

On line 411 there is:

diff := v.Values.(float64) - lastValueFromPreviousChunk.Values.(float64)

Which I guess needs to be checked for type as well.
I don't mind putting in a PR, signing CLA and normal PR is what is needed?

[dahankzter]

Care for a review @jwilder ?

[jwilder]

Yeah, looks like there is another place expecting a float64. Can you submit a PR with just the fix? It looks like you added a non_integer_derivative function as well which is separate from this issue.

[dahankzter]

I modded this one if it is ok? I just didn't really grok how it was architected when I did that. Thanks for pointing it out. Is it ok now?

[randywallace]

@dahankzter regarding your comment about master RPM builds and pushing the maintenance to ops, this ops guy suggests that you request from your ops guy/team a server provisioned with docker and that you draft a Dockerfile for InfluxDB that takes a ENV Variable/ARG option of a tag/branch/commit/fork/etc... which defaults to the latest HEAD of master of this repo; with this, managing the latest/preferred version of InfluxDB is easy for Ops and you, and doesn't require the InfluxDB maintainers to entertain the tooling of regular repo snapshots of HEAD.

[dahankzter]

Yes @randywallace that would be awesome. We have this whole debate about tools like docker et al with ops and hosting providers. The dust has not settled yet unfortunately. I can probably convince them that it is not that hard to build Go code reliably but the change in mindset can be hard.

Good idea though and I will definitely bring it to the table, thanks!