Where
asap-query-engine/src/engines/simple_engine/sql.rs, build_spatiotemporal_context (currently around line 736-737):
let duration_secs = match_result.outer_data()?.time_info.get_duration() as u64;
let start_timestamp = end_timestamp - (duration_secs * 1000);
TimeInfo::get_duration() returns f64 seconds. Casting straight to u64 before multiplying by 1000 truncates any sub-second component — e.g. a genuine 0.3s duration becomes 0u64, so the computed offset is 0ms instead of 300ms.
Found while fixing the same shape of bug in build_query_requirements_sql's data_range_ms computation as part of #500 (Phase A1). This one is the same class of bug but predates that diff, so it's out of scope for #500's minimal, behavior-preserving steps and is being filed separately instead.
The identical pattern also exists (twice) in calculate_start_timestamp_sql, but that function is dead code scheduled for deletion in #500's Phase A2 (SQL dispatcher unification), so it goes away on its own there.
Reachability
Whether this is reachable in practice depends on whether any SQL query can produce a fractional-second duration (e.g. one bound resolved via bare NOW() and the other via an absolute literal, if the runtime query_time passed to the engine isn't second-aligned) and whether data_ingestion_interval_ms is ever sub-second in deployment. Not yet confirmed either way.
Where
asap-query-engine/src/engines/simple_engine/sql.rs,build_spatiotemporal_context(currently around line 736-737):TimeInfo::get_duration()returnsf64seconds. Casting straight tou64before multiplying by 1000 truncates any sub-second component — e.g. a genuine 0.3s duration becomes0u64, so the computed offset is 0ms instead of 300ms.Found while fixing the same shape of bug in
build_query_requirements_sql'sdata_range_mscomputation as part of #500 (Phase A1). This one is the same class of bug but predates that diff, so it's out of scope for #500's minimal, behavior-preserving steps and is being filed separately instead.The identical pattern also exists (twice) in
calculate_start_timestamp_sql, but that function is dead code scheduled for deletion in #500's Phase A2 (SQL dispatcher unification), so it goes away on its own there.Reachability
Whether this is reachable in practice depends on whether any SQL query can produce a fractional-second
duration(e.g. one bound resolved via bareNOW()and the other via an absolute literal, if the runtimequery_timepassed to the engine isn't second-aligned) and whetherdata_ingestion_interval_msis ever sub-second in deployment. Not yet confirmed either way.