This bug can reappear by replaying the test case IoTDBAggregationIT.firstTest in a 3 nodes with 2 replicas cluster.
The main reason:
Consider this query in the above IT
If we query by DESC, the ascending == false, and we get the AggregationResult is FirstValueDescAggrResult, which should read data in decending order and calculate result.
Howerver, in the AggregationExecutor.aggregateOneSeries, the reader generated is also a decending one, it will return a descending read BatchData when calling AggregationResult.updateResultFromPageData().
Now let's investigate the implementation of FirstValueDescAggrResult.updateResultFromPageData(BatchData). It 'treats' the input BatchData as an ascending read sequence one(it will return the first data without any loop), which is a contradiction with the reader generated, thus the bug occurs.
Here is a brief explain:
The page data in order: 1,2,3
The generated decending reader page data with the read sequence: 3,2,1
And the FirstValueDescAggrResult will return the first one data, '3', which is different from our expected '1'
So I think the best solution is
1. Fix FirstValueDescAggrResult implementation.
2. put the AggregationResult in an ascResultList and descResultList according to the method AggregationResult.isAscending().
And we should add a comment to the abstract class AggregationResult interface.