Expected type range vector in call to function "delta", got instant vector about promxy HOT 6 OPEN

First off; thanks for reporting!

I took a look into this real quick and I'm surprised that the first query works on the old datasource. When I put that into prometheus I get an error -- because the delta is expecting a range vector not a single point in time. So with that this first error seems to be what the prometheus behavior is (maybe VM has some default range feature?) -- but this seems like its "working as intended".

As it is now; with promxy pointing at demo.robustperception.io:9090 with the following query I am unable to reproduce the error:

delta(sum(prometheus_http_requests_total{job="prometheus"}) by (code)[5m:10s])-delta(sum(prometheus_http_requests_total{job="prometheus"}) by (code)[5m:10s])

BUT! the error you are pasting is a nil pointer error not a "query error" (meaning the query was valid; it just exploded somewhere trying to fulfill it). If you take a look either in the server logs or in the response there should actually be a big backtrace -- if you could provide that it would speed up the debugging (as of right now I'm not seeing anything obvious; but if it was I guess some test would have caught it already :D ). Definitely looking forward to the trace here; thankfully with that trace nil pointer fixes are generally easy fixes.

from promxy.

Thanks for the the reply!

In parallel, I had opened a support case with VictoriaMetrics and figured I'd post their reply here...

I've made a research for range vector type error.

I found out that lookbehind window is required param for query_range requests at prometheus standard.

E.g. delta(metric[1d]) must have lookbehind window 1d. VictoriaMetrics allows skip this field and detect it automatically, based on distance between sample timestamps.

Since, promxy uses standard prometheus library for parsing expressions, it enforces those parameter for any range queries.

I'll try to get a trace log for you soon.

from promxy.

Well, I can't seem to reproduce the nil pointer error! That one may have been fixed by the upgrade to v0.0.85, I wasn't focused on this error as much as the original.

The range vector error still exists and, to be clear, the query without range and resolution runs fine against both VictoriaMetrics datasources, but fails when ran against Promxy.

from promxy.

Well, I can't seem to reproduce the nil pointer error!

Well thats at least some good news.

The range vector error still exists and, to be clear, the query without range and resolution runs fine against both VictoriaMetrics datasources, but fails when ran against Promxy.

Unfortunately there is little to be done on this. I actually get the same error running this query against prometheus directly as well. Getting a little into the detail there (hopefully providing some more context on the VM response); basically the promql spec requires that range to be defined; but VM has some automagic logic (VictoriaMetrics allows skip this field and detect it automatically, based on distance between sample timestamps. ) -- which doesn't exist in the promql library promxy is based off of. So until upstream prometheus supports that query -- or VM's promql library is refactored to be re-used here there's not a lot to do for this issue.

As much as I hate to say it -- its "working as expected". This is a somewhat unfortunate side-effect of some of the VM "improvements" as a lot of these deviate from the spec/standard which causes some of these edges.

from promxy.

Was hoping for a a more favorable solution, but I get it, and thank you for your help!

from promxy.