What happened
Some malformed or omitted aggregation parameters are silently replaced with defaults or interpreted as a different operation. Examples include missing or non-boolean count-events configuration defaulting to true, invalid HLL precision falling back to the default precision, and unrecognized Min/Max subtypes being interpreted as Min.
What I expected
Missing parameters should be defaulted only when omission is explicitly supported. Present-but-invalid parameters must fail configuration or plan creation with a clear error. A typo must never change the aggregation semantics.
Steps to reproduce
- Create an aggregation configuration with a malformed parameter type, out-of-range HLL precision, or misspelled Min/Max subtype.
- Build the corresponding accumulator or streaming plan.
- Observe that construction succeeds with a default or different semantic operation.
Additional context
Use explicit parsing that distinguishes missing from invalid values. Validate ranges and accepted enum values at the planner/configuration boundary, and add regression tests for each invalid case.
Concrete examples
These configurations should be rejected:
count_events: yes
precision: 20
min/max subtype: Mxa
Current behavior can interpret them as:
count_events: true
precision: 14
operation: Min
That means a typo can change the aggregate while the plan still succeeds. Missing values may use an intentional default, but present values with the wrong type, invalid range, or unknown enum value must return an error.
What happened
Some malformed or omitted aggregation parameters are silently replaced with defaults or interpreted as a different operation. Examples include missing or non-boolean count-events configuration defaulting to true, invalid HLL precision falling back to the default precision, and unrecognized Min/Max subtypes being interpreted as Min.
What I expected
Missing parameters should be defaulted only when omission is explicitly supported. Present-but-invalid parameters must fail configuration or plan creation with a clear error. A typo must never change the aggregation semantics.
Steps to reproduce
Additional context
Use explicit parsing that distinguishes missing from invalid values. Validate ranges and accepted enum values at the planner/configuration boundary, and add regression tests for each invalid case.
Concrete examples
These configurations should be rejected:
count_events: yes
precision: 20
min/max subtype: Mxa
Current behavior can interpret them as:
count_events: true
precision: 14
operation: Min
That means a typo can change the aggregate while the plan still succeeds. Missing values may use an intentional default, but present values with the wrong type, invalid range, or unknown enum value must return an error.