asap-planner-rs/src/planner/elastic_dsl.rs:79-99 (ElasticSingleQueryProcessor::get_streaming_aggregation_configs) has its own reimplementation of window sizing, independent of sql_utilities::QueryType:
let window = if duration == self.data_ingestion_interval_ms {
self.data_ingestion_interval_ms
} else {
t_repeat_ms
};
This is the same shape as the bug #500 fixed in asap-planner-rs/src/planner/sql.rs::compute_sql_window: t_repeat_ms is used uncapped in the else branch, even when it exceeds the query's own duration (a precompute window sized larger than the range it answers).
Per the existing project convention that Elastic planner/engine logic should match SQL's behavior rather than invent independent logic (issue #485), this should get the same fix: enforce t_repeat_ms >= data_ingestion_interval_ms and duration_ms >= t_repeat_ms, then use t_repeat_ms as window_size_ms, returning an error otherwise instead of silently building an oversized window.
asap-planner-rs/src/planner/elastic_dsl.rs:79-99 (ElasticSingleQueryProcessor::get_streaming_aggregation_configs) has its own reimplementation of window sizing, independent of sql_utilities::QueryType:
This is the same shape as the bug #500 fixed in asap-planner-rs/src/planner/sql.rs::compute_sql_window: t_repeat_ms is used uncapped in the else branch, even when it exceeds the query's own duration (a precompute window sized larger than the range it answers).
Per the existing project convention that Elastic planner/engine logic should match SQL's behavior rather than invent independent logic (issue #485), this should get the same fix: enforce t_repeat_ms >= data_ingestion_interval_ms and duration_ms >= t_repeat_ms, then use t_repeat_ms as window_size_ms, returning an error otherwise instead of silently building an oversized window.