Hi Yuan, Xuan, +1 on including this in 2.0.11. Here is some verification data from a downstream integration, in case it is useful for the release decision.
I could reproduce the wrong result on the released standalone images of both 2.0.8 and 2.0.10, and through the time-bucketed downsampling shape rather than a tag GROUP BY: SELECT date_bin(1000ms, time, 1000) AS bucket_ts, MAX(COALESCE(double_v, CAST(long_v AS DOUBLE))) AS agg_num, ... FROM telemetry WHERE <identity predicates> AND time >= 1000 AND time < 3000 GROUP BY 1 With two rows of -5.0 and -3.0 in one bucket, agg_num comes back NULL on both builds. The same window returns the correct -3.0 when the query is issued without GROUP BY. An all-zero bucket also returns NULL, and a bucket of positive values is correct. MIN over the same expression, and AVG, SUM and COUNT, are all correct, and MAX(long_v) is correct, which matches the FLOAT/DOUBLE-only sentinel analysis in your report. On affected versions: the Float.MIN_VALUE / Double.MIN_VALUE initialization is present in every release tag I checked (v2.0.4, v2.0.6, v2.0.8 and v2.0.10), and the commit that introduced it is already contained in v2.0.2, so this does not look like a recent regression. On severity, the reason I would argue for 2.0.11: the failure is silent. In the ThingsBoard Table Mode integration in iotdb-extras, the aggregation DAO treats a NULL aggregate for a bucket as "this bucket has no data" and skips it. So a MAX downsampling query over, for example, a sub-zero temperature sensor does not return a wrong number that someone would notice -- it returns no points at all for those buckets, and nothing reports an error anywhere. I only found it because of this thread, and I have opened a client-side workaround for it (iotdb-extras#116) so that the integration stays correct on current releases. One more data point on workarounds, in case anyone hits this before upgrading: projecting the raw column instead of an expression is not reliable. In my runs MAX(double_v) returned the correct value for a group where every row had a non-null double_v, but returned NULL for a group where double_v was a mix of NULLs and negative values, which is the normal case for a schema that stores one typed value column per row. Computing -MIN(-x) did work on both builds, since the grouped MIN accumulator seeds with MAX_VALUE, which is a correct sentinel for every finite double. Thanks Yuan for the quick root cause and fix. Best regards, Zihan Dai On Fri, Jul 24, 2026 07:10 PM, Yuan Tian <[email protected]> wrote: > I think it's a critical bug, we need to include that into the 2.0.11 > version, what do other people think? >
