The results of the aggregation query do not meet expectations

[zhiwangdu]

Steps to reproduce:
List the minimal actions needed to reproduce the behaviour.

1. use influxdb v1.12
2. write data
   There are two sets of data here:
   test88:

test88,tagkey=a,year_v=2025 v1=1,v2=6.6,v3=2 1748707200000000000
test88,tagkey=b,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test88,tagkey=c,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test88,tagkey=d,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test88,tagkey=e,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test88,tagkey=f,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test88,tagkey=g,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test88,tagkey=h,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test88,tagkey=i,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test88,tagkey=j,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test88,tagkey=k,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test88,tagkey=l,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test88,tagkey=m,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test88,tagkey=n,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test88,tagkey=o,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test88,tagkey=p,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test88,tagkey=q,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000

test99:

test99,tagkey=z,year_v=2025 v1=1,v2=6.6,v3=2 1748707200000000000
test99,tagkey=b,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test99,tagkey=c,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test99,tagkey=d,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test99,tagkey=e,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test99,tagkey=f,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test99,tagkey=g,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test99,tagkey=h,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test99,tagkey=i,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test99,tagkey=j,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test99,tagkey=k,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test99,tagkey=l,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test99,tagkey=m,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test99,tagkey=n,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test99,tagkey=o,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test99,tagkey=p,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000
test99,tagkey=q,year_v=2025 v1=0,v2=6.6,v3=0 1751299200000000000

Expected behaviour:
Describe what you expected to happen.
Use the following InfluxQL query to retrieve the above two sets of data.

select station_code, time, v3, v1, v2 from (select max(v3) as v3, sum(v1) as v1, sum(v2) as v2 from autogen.test88 where time >='2024-12-31 16:00:00' and time <= '2025-12-31 15:59:59' group by tagkey,year_v) where time >='2024-12-31 16:00:00' and time <= '2025-12-31 15:59:59' order by time desc  limit 20 offset 0

Both test88 and test99 are expected to return 17 lines of data.

Actual behaviour:
Describe What actually happened.
test99 returned 18 lines of data, and tagkey=z was split into two lines in the return.

Environment info:

• Please provide the command you used to build the project, including any RUSTFLAGS.
• System info: Run uname -srm or similar and copy the output here (we want to know your OS, architecture etc).
• If you're running IOx in a containerised environment then details about that would be helpful.
• Other relevant environment details: disk info, hardware setup etc.

Config:
Copy any non-default config values here or attach the full config as a gist or file.

Logs:
Include snippet of errors in logs or stack traces here.
Sometimes you can get useful information by running the program with the RUST_BACKTRACE=full environment variable.
Finally, the IOx server has a -vv for verbose logging.

[philjb]

Hi @zhiwangdu -- thanks for your report: I have been able to reproduce it following your instructions. (s/station_code/tagkey)

It is surprising that for identical data, except for one tag value, the results of the outer query are different.

I note that the results of the inner query appear correct(expected). I also note that select count(*) from (select max(v3)... test99 returns 17 which is the correct series count. It appears to be a cursor issue, perhaps a sorting issue with tag series.

Nest queries/subqueries are interesting situations.

The reproduction steps should make it easy to track down in a test case with the debugger.

How did you find this issue? Was it like your report in #26651?

[zhiwangdu]

Hi @zhiwangdu -- thanks for your report: I have been able to reproduce it following your instructions. (s/station_code/tagkey)

It is surprising that for identical data, except for one tag value, the results of the outer query are different.

I note that the results of the inner query appear correct(expected). I also note that select count(*) from (select max(v3)... test99 returns 17 which is the correct series count. It appears to be a cursor issue, perhaps a sorting issue with tag series.

Nest queries/subqueries are interesting situations.

The reproduction steps should make it easy to track down in a test case with the debugger.

How did you find this issue? Was it like your report in #26651?

I want to implement pagination for the query below, but slimit and soffset are not work in a multi-shard setup, so I used a nested subquery to achieve this, which led to discovering this issue:

select max(v3) as v3, sum(v1) as v1, sum(v2) as v2 from autogen.test88 where time >='2024-12-31 16:00:00' and time <= '2025-12-31 15:59:59' group by tagkey,year_v

[zhiwangdu]

Hi @philjb

After debugging, I identified the following causes of the issue:

1. Inconsistent Time Handling in Selector and Aggregate Functions
Selector functions (e.g., max/min) retain the actual timestamp of the data, while Aggregate functions (e.g., sum/count) use the window timestamp and do not include the actual timestamp. This leads to inconsistent results when sorting by time.
Relevant code:

https://github.com/influxdata/influxdb/blob/master-1.x/query/call_iterator.go#L244
https://github.com/influxdata/influxdb/blob/master-1.x/query/call_iterator.go#L302
https://github.com/influxdata/influxdb/blob/master-1.x/query/iterator.gen.go#L1160

2. Missing Dimension Option in SubQuery IteratorOption
The IteratorOption for subqueries does not include the Dimension option, causing subquery results for different fields to be merged with inconsistent sorting, resulting in data misalignment.
Relevant code:

https://github.com/influxdata/influxdb/blob/master-1.x/query/iterator.go#L728

These issues result in data misalignment in the final iteration output.

Are there any recommended solutions or approaches to address these problems?

[philjb]

Hey @zhiwangdu -- I think you've identified a bug at least for the data misalignment issue. For your first point, keeping the original timestamp for min/max makes sense as there's a definite timestamp associated with the max (or min or first or last) value. It also makes sense that for sum count mean, stddev etc which timestamp to pick is not clear as many timestamps went into the aggregate. The former are reducers that select a single point; the latter are reducers that combine points into a single new point (as you know). The latter all seem to use the beginning of the query window as the new point timestamp. While not unreasonable, the code could have been written to pick the timestamp of the first/last input point, the middle, etc.

The issue seems to be that when combining single point selectors with many point aggregators, sorting by time has lost meaning somewhat. I think the current code is "correct" if potentially unexpected.

For your second point about dimension options, I think this is the bug. Albeit quite an old one. It shouldn't be splitting series for the output as the query requested grouping by tagkey. I don't think there's a way to workaround this without a bug fix.

You could not do the subquery and instead process the data in your client code. But as you mention, that's less ideal for pagination where you really need the database to handle the limit and offset.