can't use aggregations that return floats

[seiflotfy]

somehow

vercel
| where isnotnull(['request.path']) and isnotnull(['request.statusCode'])
| summarize avg(['report.durationMs']) by bin_auto(_time), ['request.path']
| limit 20

won't work. If we switch the avg with sum it works. Seems like we have an issue with casting?

[mschoch]

That's odd, we actually use float64 for all the aggregations, I'll have to look into this

[mschoch]

Here is the underlying error: interface conversion: interface {} is nil, not float64

goroutine 10 [running]:     
runtime/debug.Stack()     
     /Users/mschoch/Documents/goroot/src/runtime/debug/stack.go:24 +0x64     
github.com/axiomhq/axiom-grafana/pkg/plugin.(*Datasource).QueryData.func1()     
     /Users/mschoch/clients/axiom-grafana/pkg/plugin/datasource.go:100 +0x114     
panic({0x7dac00, 0x4000323650})     
     /Users/mschoch/Documents/goroot/src/runtime/panic.go:884 +0x1f4     
github.com/grafana/grafana-plugin-sdk-go/data.(*float64Vector).Append(0x400021b158?, {0x0?, 0x0?})     
     /Users/mschoch/go/pkg/mod/github.com/grafana/grafana-plugin-sdk-go@v0.160.0/data/vector.gen.go:682 +0xc8     
github.com/grafana/grafana-plugin-sdk-go/data.(*Frame).AppendRow(...)     
     /Users/mschoch/go/pkg/mod/github.com/grafana/grafana-plugin-sdk-go@v0.160.0/data/frame.go:103     
github.com/axiomhq/axiom-grafana/pkg/plugin.buildFrameSeries(0x40000ca6c0)     
     /Users/mschoch/clients/axiom-grafana/pkg/plugin/datasource.go:240 +0x708     
github.com/axiomhq/axiom-grafana/pkg/plugin.(*Datasource).query(0x707b0?, {0xa03e78, 0x40003e3d10}, {0x40001192e8?, 0x1a040?}, {0x1, {0x40000c60d8, 0x18}, 0x400039ad80, 0x0, ...}, ...)     
     /Users/mschoch/clients/axiom-grafana/pkg/plugin/datasource.go:151 +0x1f8     
github.com/axiomhq/axiom-grafana/pkg/plugin.(*Datasource).QueryData(0x40000b4d38, {0xa03e78, 0x40003e3d10}, 0x40000c1bd0)     
     /Users/mschoch/clients/axiom-grafana/pkg/plugin/datasource.go:109 +0x168     
github.com/grafana/grafana-plugin-sdk-go/internal/automanagement.(*Manager).QueryData(0xa03e78?, {0xa03e78, 0x40003e3d10}, 0x40000c1bd0)     
     /Users/mschoch/go/pkg/mod/github.com/grafana/grafana-plugin-sdk-go@v0.160.0/internal/automanagement/manager.go:33 +0x184     
github.com/grafana/grafana-plugin-sdk-go/backend.(*dataSDKAdapter).QueryData(0x4000419d00, {0xa03e78, 0x40003e3d10}, 0x0?)     
     /Users/mschoch/go/pkg/mod/github.com/grafana/grafana-plugin-sdk-go@v0.160.0/backend/data_adapter.go:45 +0x7c     
github.com/grafana/grafana-plugin-sdk-go/backend/grpcplugin.(*dataGRPCServer).QueryData(0x8e9aa8?, {0xa03e78?, 0x40003e3d10?}, 0x40003e3ce0?)     
     /Users/mschoch/go/pkg/mod/github.com/grafana/grafana-plugin-sdk-go@v0.160.0/backend/grpcplugin/grpc_data.go:47 +0x30     
github.com/grafana/grafana-plugin-sdk-go/genproto/pluginv2._Data_QueryData_Handler.func1({0xa03e78, 0x40003e3d10}, {0x864560?, 0x40000c0140})     
     /Users/mschoch/go/pkg/mod/github.com/grafana/grafana-plugin-sdk-go@v0.160.0/genproto/pluginv2/backend_grpc.pb.go:195 +0x74     
github.com/grpc-ecosystem/go-grpc-prometheus.(*ServerMetrics).UnaryServerInterceptor.func1({0xa03e78, 0x40003e3d10}, {0x864560, 0x40000c0140}, 0x40001195f8?, 0x40000b4bb8)     
     /Users/mschoch/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-prometheus@v1.2.0/server_metrics.go:107 +0x74     
github.com/grpc-ecosystem/go-grpc-middleware.ChainUnaryServer.func2.1({0xa03e78?, 0x40003e3d10?}, {0x864560?, 0x40000c0140?})     
     /Users/mschoch/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware@v1.4.0/chain.go:48 +0x50     
go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc.UnaryServerInterceptor.func1({0xa03e78, 0x40003e2480}, {0x864560, 0x40000c0140}, 0x40000be4e0, 0x400039aa00)     
     /Users/mschoch/go/pkg/mod/go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc@v0.40.0/interceptor.go:342 +0x3d0     
github.com/grpc-ecosystem/go-grpc-middleware.ChainUnaryServer.func2({0xa03e78, 0x40003e2480}, {0x864560, 0x40000c0140}, 0x40000be4e0, 0x5f860c?)     
     /Users/mschoch/go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware@v1.4.0/chain.go:53 +0x158     
github.com/grafana/grafana-plugin-sdk-go/genproto/pluginv2._Data_QueryData_Handler({0x7b6520?, 0x4000510090}, {0xa03e78, 0x40003e2480}, 0x40003e0000, 0x40004e67e0)     
     /Users/mschoch/go/pkg/mod/github.com/grafana/grafana-plugin-sdk-go@v0.160.0/genproto/pluginv2/backend_grpc.pb.go:197 +0x12c     
google.golang.org/grpc.(*Server).processUnaryRPC(0x40004f6000, {0xa08ed8, 0x4000003a00}, 0x40003ae360, 0x40004e6ed0, 0xfb35e0, 0x0)     
     /Users/mschoch/go/pkg/mod/google.golang.org/grpc@v1.54.0/server.go:1345 +0xc28     
google.golang.org/grpc.(*Server).handleStream(0x40004f6000, {0xa08ed8, 0x4000003a00}, 0x40003ae360, 0x0)     
     /Users/mschoch/go/pkg/mod/google.golang.org/grpc@v1.54.0/server.go:1722 +0x80c     
google.golang.org/grpc.(*Server).serveStreams.func1.2()     
     /Users/mschoch/go/pkg/mod/google.golang.org/grpc@v1.54.0/server.go:966 +0x84     
created by google.golang.org/grpc.(*Server).serveStreams.func1     
     /Users/mschoch/go/pkg/mod/google.golang.org/grpc@v1.54.0/server.go:964 +0x278   

[mschoch]

Sorry that stack trace is from my latest PR branch, line numbers may not be helpful

[mschoch]

@seiflotfy I see null's coming back in the response (in Axiom UI), I'm not sure what to replace these with in the plugin. If I omit them, it complains that the values slices are not the same length. But, putting 0 in there feels wrong too...

[mschoch]

OK, so one fix is that we can define the field values to be []*float64 instead of []float64 which it is today, and then if the value isn't float64, we set it to nil. I have tested this, and while it seems to work... That query you sent me renders more like individual points rather than lines now, I think possibly the nils make it render discontinuously? But perhaps that is a grafana level visual option to play with (I don't even know what behavior you expect)

Here is what it looks like in Grafana with the change I mentioned above, and what it looks like in Axiom:

I did try one other chart I had available and it still rendered as a line (expected), so I think that issue might be related to the data.