fix: SelectSeries not correct for single reports

[simonswine]

Summary

Fixes an issue where SelectSeries queries return incorrectly formatted time series data when only a single report is processed. The query backend was skipping the aggregation step for single reports, but for time series queries, the aggregation function is critical for ensuring proper ordering and correctness of the data structure.

Problem

The query backend only calls aggregate functions when there is more than one report for a particular type. For time series queries, this caused issues because the aggregate function also ensures the order and correctness of the data shape, not just combining multiple reports.

Solution

• Added an alwaysAggregate flag to the query type registration system
• Time series queries now always call their aggregate function, even for single reports
• Other query types maintain their existing behavior (only aggregating when multiple reports exist)

Changes

• Modified registerQueryType() to accept an alwaysAggregate parameter (pkg/querybackend/query.go:70)
• Updated report_aggregator.go to track and check which report types require aggregation for single reports
• Set alwaysAggregate: true for time series queries (pkg/querybackend/query_time_series.go:25)
• Added comprehensive test coverage:
  • New test Test_QueryTimeSeriesOneReport() validates single report behavior (pkg/querybackend/block_reader_test.go:274)
  • Added test fixtures for expected time series output
  • All other query types explicitly set to alwaysAggregate: false

Test Plan

• ✅ Existing tests continue to pass
• ✅ New test validates single report time series formatting
• ✅ Test fixtures ensure correct data structure and ordering

🤖 Generated with Claude Code

[aleks-p]

I tried it locally and the issue and the proposed fix make sense to me.

To add to the generated description, what happens is that before aggregation we return valid series data, however the points are not aligned to the step and are not aggregated by time, because we rely on post-processing to handle this.

We could in theory improve the individual reports as we generate them and avoid the special handling, but we will be doing extra work since we still need to pass through the (processed) data again when we have multiple reports.

[simonswine]

We could in theory improve the individual reports as we generate them and avoid the special handling, but we will be doing extra work since we still need to pass through the (processed) data again when we have multiple reports.

This was in fact the first fix I had, it felt like we are doing the majority of cases more work than necessary, that's why I have implemented it in that way.