fix(planner): Elastic DSL window size falls back to t_repeat_ms instead of actual query duration #485

Summary

ElasticSingleQueryProcessor::get_streaming_aggregation_configs picks the tumbling window size used to build a query's sketches. For any time-range query whose duration isn't exactly equal to data_ingestion_interval_ms, the window size is hardcoded to t_repeat_ms, discarding the actual queried duration computed a few lines earlier.

Location

asap-planner-rs/src/planner/elastic_dsl.rs:79-101

let window = if duration == self.data_ingestion_interval_ms {
    self.data_ingestion_interval_ms
} else {
    t_repeat_ms   // <- actual `duration` is discarded here
};

Impact

Sketches get built over windows sized by t_repeat_ms, not by what the query actually asked for. E.g. a query for the last 1s of data with t_repeat_ms=30s still aggregates 30s of data into the underlying sketch — data outside the requested range leaks into the result, and it can't be un-merged at query time.

Current status

This is not just unfixed — it's pinned as expected behavior by a test added in #457 (fix(planner): fixed bug in Elastic query processor where it wasn't using data_ingestion_interval_ms):
asap-planner-rs/tests/elastic_dsl_integration.rs:576-589, time_range_longer_than_ingestion_interval_uses_t_repeat_as_window_size, comment: // Temporal: window = t_repeat_ms.

#457 fixed a related-but-different problem (rejecting queries with no time-range predicate, or ranges shorter than the ingestion interval); it did not address the window-size-vs-duration mismatch.