aggregateSeries panics on differing series lengths

[arodland]

(Meta-issue: #161).

When passing series with different lengths to functions that use aggregateSeries (sumSeries, avgSeries, etc. including groupByNode on these things), not only is it not handled properly, we actually get a (recovered) panic.

Failing query (from error logs):

removeEmptySeries(groupByNode(scaleToSeconds(statsite.counts.{skyfire,akfire,l3fire,l3l3fire}.lb.chopshop*.ext_status.*.[1-5]*, 1), 6, 'sum'))

Stack trace (carbonapi is aa9a8a654a2c8db6add1c18fb74b320a9cd18f73).

[Dieterbe]

shouldn't series be assured to have the same length before being passed into processing functions (e.g. right after fetching)?

[blysik]

I'm seeing this error also. (Using sumSeries)

[Civil]

I think that's a duplicate of https://github.com/go-graphite/carbonapi/issues/161

[maggnus]

Aggregation functions doesn't work when gaps in data series exists.

{"cache_key": "format=json&from=-30d&maxDataPoints=1622&target=maxSeries%28wahoo.sg%2A.wahoo.turn.campaigns.xfer-latency-ms%29&until=now", "stack": "main.renderHandler.func3.1 /root/go/src/github.com/go-graphite/carbonapi/main.go:522 runtime.call32 /usr/local/go/src/runtime/asm_amd64.s:514 runtime.gopanic /usr/local/go/src/runtime/panic.go:489 runtime.panicindex /usr/local/go/src/runtime/panic.go:28 github.com/go-graphite/carbonapi/expr.aggregateSeries /root/go/src/github.com/go-graphite/carbonapi/expr/expr.go:4140 github.com/go-graphite/carbonapi/expr.EvalExpr /root/go/src/github.com/go-graphite/carbonapi/expr/expr.go:2206 main.renderHandler.func3 /root/go/src/github.com/go-graphite/carbonapi/main.go:526 main.renderHandler /root/go/src/github.com/go-graphite/carbonapi/main.go:534 net/http.HandlerFunc.ServeHTTP /usr/local/go/src/net/http/server.go:1942 net/http.(*ServeMux).ServeHTTP /usr/local/go/src/net/http/server.go:2238 github.com/go-graphite/carbonapi/vendor/github.com/gorilla/handlers.CompressHandlerLevel.func1 /root/go/src/github.com/go-graphite/carbonapi/vendor/github.com/gorilla/handlers/compress.go:146 net/http.HandlerFunc.ServeHTTP /usr/local/go/src/net/http/server.go:1942 github.com/go-graphite/carbonapi/vendor/github.com/gorilla/handlers.(*cors).ServeHTTP /root/go/src/github.com/go-graphite/carbonapi/vendor/github.com/gorilla/handlers/cors.go:128 github.com/go-graphite/carbonapi/vendor/github.com/gorilla/handlers.ProxyHeaders.func1 /root/go/src/github.com/go-graphite/carbonapi/vendor/github.com/gorilla/handlers/proxy_headers.go:59 net/http.HandlerFunc.ServeHTTP /usr/local/go/src/net/http/server.go:1942 net/http.serverHandler.ServeHTTP /usr/local/go/src/net/http/server.go:2568 net/http.(*conn).serve /usr/local/go/src/net/http/server.go:1825"}

[joemiller]

We are starting to run into this issue more frequently as time goes by and we collect various little blips and gaps in our series. I'd like to help try to resolve it if possible. Is there any work in progress or tips toward a possible solution that I could look at to come up to speed?

[Civil]

There are plans on fixing that issue. Though I can't tell when this will actually happen. I really hope that I'll be able to finish that by the end of this month (at least as a draft), but no promises at all.

I think a good approach might be to talk metrictank guys to relicense their code around consolidation under less viral license and use their code as a base for consolidator for carbonapi (it can't be reused directly anyways). Another way is to adapt https://github.com/lomik/graphite-clickhouse/tree/master/helper/rollup

There are some requirements for the code - it should be general enough to be used by other projects (cause it will probably be migrated to carbonzipper at some point) and pluggable (in future there'll be more consolidation algorithms). But the code should be pretty straightforward.

[Civil]

As far as I understand that should no longer happen in current master and actually since approx. 0.15.4 or so. If that is still a problem, please reopen.