[Bug] ALTER TABLE changing ROW binlog.format returns wrong error message

[MoanasDaddyXu]

Search before asking

• I had searched in the issues and found no similar issues.

Version

Reproduced with the table stream regression case on local Doris HEAD d4a077caf8a.

Test environment:

regression-test/suites/table_stream_p0/test_binlog_property_alter_exception.groovy
remote log: /mnt/disk1/jianxu/case_output/doris/testrun/table_stream_p0_20260708/test_binlog_property_alter_exception.final.log
FE: 172.20.49.4:9030

What's Wrong?

When a table is created with ROW binlog enabled, changing binlog.format by ALTER TABLE ... SET should be rejected by the binlog format validation path.

The regression case expects an exception message containing:

not support change binlog format

However, Doris currently returns a generic light schema change error:

errCode = 2, detailMessage = only support light schema change operator when use table with binlog<Row>

This makes test_binlog_property_alter_exception fail on the first ALTER TABLE check.

What You Expected?

Changing binlog.format after table creation should fail with a clear binlog format error, for example:

not support change binlog format

How to Reproduce?

Regression case:

regression-test/suites/table_stream_p0/test_binlog_property_alter_exception.groovy

Failing SQL:

ALTER TABLE tbl_row_fmt SET ("binlog.format" = "STATEMENT_AND_SNAPSHOT");

Minimal flow:

CREATE TABLE tbl_row_fmt (
    k1 INT,
    v1 INT
)
UNIQUE KEY(k1)
DISTRIBUTED BY HASH(k1) BUCKETS 1
PROPERTIES (
    "replication_num" = "1",
    "enable_unique_key_merge_on_write" = "true",
    "binlog.enable" = "true",
    "binlog.format" = "ROW"
);

ALTER TABLE tbl_row_fmt SET ("binlog.format" = "STATEMENT_AND_SNAPSHOT");

Regression Test Result

suite: test_binlog_property_alter_exception
command: ALTER TABLE tbl_row_fmt SET ("binlog.format" = "STATEMENT_AND_SNAPSHOT")
expected: exception message contains "not support change binlog format"
actual: errCode = 2, detailMessage = only support light schema change operator when use table with binlog<Row>

Log excerpt:

2026-07-08 18:04:09.369 INFO  - Execute sql:
ALTER TABLE tbl_row_fmt SET ("binlog.format" = "STATEMENT_AND_SNAPSHOT")
2026-07-08 18:04:09.382 ERROR - Exception: java.sql.SQLException: errCode = 2, detailMessage = only support light schema change operator when use table with binlog<Row>
Caused by: java.lang.AssertionError: Expect exception msg contains 'not support change binlog format', but meet 'java.sql.SQLException: errCode = 2, detailMessage = only support light schema change operator when use table with binlog<Row>'

Anything Else?

Tracking issue: #65265

Are you willing to submit PR?

• Yes I am willing to submit a PR!

[zclllyybb]

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

Initial analysis for #65383:

This looks like a real FE validation-order bug, not only a regression-test expectation problem.

What I checked:

• The live issue is open, has no labels/comments at read time, and reports Doris HEAD d4a077caf8a with a failing ALTER TABLE tbl_row_fmt SET ("binlog.format" = "STATEMENT_AND_SNAPSHOT").
• The exact short commit is not visible from the public apache/doris commit search I ran, but the same routing gap is present on refreshed upstream/master (16a745d5125).

Code path:

• ModifyTablePropertiesOp.validate() recognizes binlog.* properties and calls PropertyAnalyzer.analyzeBinlogConfig(...), but this only validates the property value shape. It does not compare the requested value with the existing table binlog config.
• The comparison that would produce the expected message is in SchemaChangeHandler.updateBinlogConfig(): it builds a new BinlogConfig and calls BinlogConfig.mergeFromProperties(..., false). BinlogConfig.mergeFromProperties() explicitly returns not support change binlog format from ROW to STATEMENT_AND_SNAPSHOT when binlog.format changes.
• However, AlterOperations.checkBinlogConfigChange() currently routes only these keys to updateBinlogConfig(): binlog.enable, binlog.ttl_seconds, binlog.max_bytes, and binlog.max_history_nums.
• It does not include binlog.format, so this statement falls through to the generic hasSchemaChangeOp() path. In SchemaChangeHandler.process(), ModifyTablePropertiesOp sets lightSchemaChange = false, and then the row-binlog guard rejects it with only support light schema change operator when use table with binlog<Row>.

So the wrong message is caused by routing binlog.format through the schema-change path before the binlog-config merge/validation path can run.

Recommended next step:

• Extend the binlog-config routing predicate to include PropertyAnalyzer.PROPERTIES_BINLOG_FORMAT.
• Also consider including PropertyAnalyzer.PROPERTIES_BINLOG_NEED_HISTORICAL_VALUE, because BinlogConfig.mergeFromProperties() has the same immutable-change check for it but checkBinlogConfigChange() currently does not route it either.
• Keep/adjust the regression to assert that changing binlog.format on an existing ROW-binlog table fails through the binlog config validator with not support change binlog format, not through the generic row-binlog schema-change guard.

Missing information:

• No additional logs are needed to identify the likely code-level cause for the reported SQL.
• If maintainers want to pin the exact introducing commit, the public issue should include a public branch/PR or full commit SHA reachable from apache/doris; the reported short SHA was not found from the public repository during this read-only check.