influxdata / influxdata/influxdb
cumulativeSum Output after group not ordered in time
- Dominant language
- Rust
- Stars
- 31.7k
- Forks
- 3.7k
- Avg merge
- 13h 37m
- Merged PRs (30d)
- 8
Description
__Steps to reproduce:__
I have counters collected from Telegraf statsd input with labels like these:
```
import statsd
c = statsd.StatsClient('localhost', 8125)
c.incr('film.viewed,title=Move')
c.incr('film.viewed,title=Elling')
c.incr('film.viewed,title=Elling,user=5')
c.incr('film.viewed,title=Elling,user=3')
c.incr('film.viewed,title=Move,user=5')
c.incr('film.viewed,title=Move,user=1')
c.incr('film.viewed,title=Kill Bill,user=5')
c.incr('film.viewed,title=Kill Bill,user=8')
c.incr('film.viewed,title=Elling,user=5')
c.incr('film.viewed,title=Move,user=5')
c.incr('film.viewed,title=Move,user=3')
c.incr('film.viewed,title=Kill Bill,user=3')
```
I am querying them like this:
```
from(bucket: "mybucket")
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
|> group(columns: ["title"], mode:"by")
|> filter(fn: (r) => r["_measurement"] == "film_viewed")
|> filter(fn: (r) => r["_field"] == "value")
|> cumulativeSum(columns: ["_value"])
|> yield(name: "views")
```
__Expected behavior:__
I would expect to get strictly increasing results for this query, one result per film title.
__Actual behavior:__
While I get results for each film title, they are somewhat funky with regards to the time domain:

Adding a ` |> sort(columns: ["_time"], desc: false)` statement improves the situation somewhat:

However, there is still a bit of weird behavior where that one film's count goes up to 6 and then rises to 7 without any change in time.
I would have expected the rise to go linearly from 5 to 7 if there are two events that were pushed by telegraf at the same time.
__Environment info:__
* System info: Linux 5.10.11-arch1-1 x86_64
* InfluxDB version: InfluxDB 2.0.4 (git: 4e7a59bb9a) build_date: 2021-02-08T17:47:02Z
Contributor guide
Research direction
Use the supplied Flux pipeline and grouped counter data as the starting reproduction, focusing on the cumulativeSum operator and its time-order handling. No repository file or test is named; locate the operator's existing tests first. Done means grouped results are ordered in time and simultaneous events produce the expected cumulative values.
Written by the indexing model from the issue text.
Assessment
- Domain
- databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100