aggregateWindow first window value - same as last in data series

[PuzzleSoft]

Hi I have seen a strange behaviour performed by aggregateWindow - with this query.

from(bucket: "GH-13-210119-01")
|> range(start: 2020-08-19T00:00:00Z, stop: 2020-08-20T00:00:00Z)
|> filter(fn: (r) => (r["_measurement"] == "history"))
|> filter(fn: (r) => (r["_field"] == "val"))
|> filter(fn: (r) => (r["tag_name"] == "CurrentSetpoint"))
//|> aggregateWindow(every: 1s, fn: mean, createEmpty: true)
//|> fill(column: "_value", usePrevious: true)
//|> aggregateWindow(every: 5m, fn: mean, createEmpty: true)
|> yield()

When running the above query (including the comments) I get the raw values from influxdb (reduced from a PostgreSql database, that contains values for each second, but only when a significant change is observed, a value can be found in influxdb):
Time val
2020-08-19T00:00:00Z 0
2020-08-19T05:09:57Z 1
2020-08-19T05:09:58Z 2.1
2020-08-19T05:09:59Z 3.1
2020-08-19T05:10:00Z 4.1

When applying the first aggregate window for every second and doing a fill with the previous value, the data are as expected (and a one second lag due to the window function, that has on importance for my application):

2020-08-19T00:00:01Z 0
2020-08-19T00:00:02Z 0
... a lot of zero's
2020-08-19T05:09:58Z 1
2020-08-19T05:09:59Z 2.1
2020-08-19T05:09:59Z 3.1
2020-08-19T05:10:00Z 4.1

Then the big surprice applying a second aggregateWindow(every: 5m, fn: mean, createEmpty: true) on the above data gives:

2020-08-19T00:00:00Z 200 !!!
2020-08-19T00:05:00Z 0
.... some zero's
2020-08-19T05:10:00Z 0.0103
2020-08-19T05:15:00Z 0.0410

The value 200 matches (in this case) the last value in the series and if I change the stop time, the value changes often accordingly to the new last value. As a matter of fact, the value is always the same value - despite the function used.

I'm using the Data Explorer and looking at the raw values

Expected behavior:
First value should be calculated according to window, values and function used

Actual behavior:
First value is often the same as the last value in the resulting data series - but not the correct value anyway.

Environment info:

• System info: Linux 5.4.0-66-generic x86_64
• InfluxDB version: InfluxDB 2.0.4 (git: 4e7a59b) build_date: 2021-02-08T17:47:02Z

Config:

• Plain installation as Debian package

[nachtbraker]

I have the same problem. Did you ever find a solution for this?

I'm using influxdb-1.8 on FreeBSD.

[PuzzleSoft]

I had to rerun the query and have a look again (influx 2.4) - because I do not remember the cause. The exact same order of values appeared - but this time I realized that the timestamps where out of order and a sort() would make the point drop to the end. I think I have manually written the timestamps in the example above - as I expected it to be. Theee is a double timestamp 2020-08-19T05:09:59Z indicating that as this would not be possible. Hope this "sorts" it out :-)