influxdata / influxdata/influxdb
Using filter in the REPL will panic when not at the beginning of a query
- Dominant language
- Rust
- Stars
- 31.7k
- Forks
- 3.7k
- Avg merge
- 13h 37m
- Merged PRs (30d)
- 8
Description
__Steps to reproduce:__
List the minimal actions needed to reproduce the behavior.
1. Construct a query where `filter()` does not get pushed down.
2. Run this query in the REPL or with `influx query` which uses the REPL code to execute the flux script.
```
from(bucket: "mydata")
|> range(start: -1h)
|> v1.fieldsAsCols()
|> filter(fn: (r) => r.usage_user > 50)
```
__Expected behavior:__
I expected the query to run or at least error at some point.
__Actual behavior:__
The server reported that it panicked because of an invalid memory address access.
It appears this happens because the spec compiler, which is used by the REPL to execute queries, does not create a resolved function correctly. It will resolve the scope to a null value when it is unmarshaled and then it will attempt to access that null scope when it compiles.
If the same query is run using `curl` then this doesn't happen.
Contributor guide
Research direction
Start with the REPL and spec compiler path used by `influx query`, then reproduce the supplied query involving `filter()` after `v1.fieldsAsCols()`. Inspect how the resolved function and scope are unmarshaled and compiled, and compare the REPL path with `curl`. Done means the query no longer panics and instead runs or reports an error.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- cli, compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 28/100