[Bug](High) ROW binlog rejects valid HLL writes with a misleading QuantileState nullable error

[MoanasDaddyXu]

Tracking

• Tracking issue: [Tracking][Binlog] Binlog feature umbrella — all sub-issues tracked here #65265
• Internal Jira: DORIS-27337

Search before asking

• I searched the existing issues and found no issue with the same error or reproduction.

Version

Reproduced while testing #62606 on Doris commit a78b707ed040c3206df99cf43ea3101ab2ba5b90.

Test environment: non-Cloud deployment with 1 FE and 3 BEs.

What's Wrong?

A UNIQUE KEY merge-on-write table can be created with a NOT NULL HLL column and ROW binlog enabled, but the first valid HLL write fails in the BE conversion path:

QuantileState column does not support nullable

The HLL column is declared NOT NULL, and the error incorrectly refers to QuantileState. The same ROW-binlog configuration can write BITMAP values successfully, so the failure is specific to the HLL ROW-binlog write path.

IVM requires ROW binlog, so this blocks IVM scenarios whose base tables contain HLL columns before refresh can begin.

What You Expected?

If HLL is supported with ROW binlog, a valid HLL_HASH value should be written successfully and produce consumable row binlog. If this combination is intentionally unsupported, Doris should reject it during CREATE/ALTER analysis with an accurate error instead of accepting the table and failing every write.

How to Reproduce?

DROP DATABASE IF EXISTS ivm_hll_row_binlog_repro;
CREATE DATABASE ivm_hll_row_binlog_repro;
USE ivm_hll_row_binlog_repro;

CREATE TABLE hll_row_binlog_base (
  id BIGINT NOT NULL,
  value HLL NOT NULL
)
UNIQUE KEY(id)
DISTRIBUTED BY HASH(id) BUCKETS 1
PROPERTIES (
  'replication_num'='1',
  'enable_unique_key_merge_on_write'='true',
  'binlog.enable'='true',
  'binlog.format'='ROW',
  'binlog.need_historical_value'='true'
);

INSERT INTO hll_row_binlog_base VALUES (1, HLL_HASH('one'));
SELECT COUNT(*) FROM hll_row_binlog_base;

The CREATE succeeds, the INSERT fails with the error above, and the table remains empty.

Regression Test Result

• Suite: ivm_sql_complex_type_matrix
• Jenkins: regression-debug #792
• Result: CREATE succeeds and the valid HLL_HASH INSERT fails consistently.

The suite currently records this behavior as a negative capability boundary and therefore passes; that pass means the failure is reproducible, not that the product behavior is correct.

Anything Else?

The failure occurs in the BE HLL column conversion path when a nullmap is present. The returned error text appears to have been copied from the QuantileState converter.

Are you willing to submit PR?

• Yes, I am willing to submit a PR!

[zclllyybb]

Breakwater-GitHub-Analysis-Slot: slot_d3817c3c4dc3
This content is generated by AI for reference only.

Initial triage from the reported commit a78b707ed040c3206df99cf43ea3101ab2ba5b90 and refreshed upstream/master:

This looks like a real BE ROW-binlog conversion bug, not invalid SQL. The table creation path accepts this schema: when FE builds the hidden ROW-binlog index, OlapTable.generateTableRowBinlogSchema() only rejects VARIANT and AUTO_INCREMENT. For non-key value columns it uses Column.generateAfterValueColumn(), and for historical values it also uses Column.generateBeforeValueColumn(); both helpers copy the original column and then set the ROW-binlog column nullable. Therefore a NOT NULL HLL base value can still be written through a nullable ROW-binlog column shape.

The failing insert matches the BE path: RowBinlogSegmentWriter::append_block() calls RowBinlogSourceDataWriter::prepare_by_source_block(), which invokes OlapBlockDataConvertor::convert_column_data() for the source column. For OLAP_FIELD_TYPE_HLL, the converter is OlapColumnDataConvertorHLL. In that converter, any present _nullmap immediately returns Status::NotSupported("QuantileState column does not support nullable"). So the observed message is a copy/paste error in the HLL branch, and the failure is triggered by the column nullable-wrapper shape, not by QuantileState.

Bitmap's converter already handles the nullable-wrapper case by unwrapping ColumnNullable, serializing non-null rows, and returning nullptr/0 slices for null rows. HLL has compatible serialized-slice behavior in the non-null branch, so the likely product fix is to make OlapColumnDataConvertorHLL handle nullable HLL like bitmap, including the all-non-null wrapper case used by this repro. If Doris intentionally does not want to support HLL in ROW binlog, the support boundary should instead be enforced in FE create/alter validation before generating the ROW-binlog index, with an HLL-specific message.

Suggested next steps:

1. Add a regression case for ROW binlog + NOT NULL HLL insert using HLL_HASH, and check row-binlog consumption if possible.
2. Fix the HLL converter to unwrap nullable HLL and serialize non-null rows, or add explicit FE validation rejecting HLL with ROW binlog.
3. Correct the error text in the HLL and AggState paths so unsupported complex types do not report QuantileState.

No additional user data is needed to confirm the primary code path. Runtime logs would only be useful if maintainers want to confirm whether the failing block contains an all-zero nullmap or an actual nullable HLL value.