[Bug] There's no error message for select @incr

[MoanasDaddyXu]

Search before asking

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

Version

doris-0.0.0-49af19213e7

What's Wrong?

There's no error message for Table Stream

CREATE TABLE base_incr_no_binlog (
k1 INT, v1 INT
)
DUPLICATE KEY(k1)
DISTRIBUTED BY HASH(k1) BUCKETS 1
PROPERTIES ("replication_num" = "1");
Query OK, 0 rows affected (0.01 sec)

SELECT k1, v1, DORIS_BINLOG_OP
FROM base_incr_no_binlog@incr("incrementType" = "DETAIL");
ERROR 1105 (HY000): errCode = 2, detailMessage =

What You Expected?

Need to replay like:
ERROR 1105 (HY000): errCode = 2, detailMessage = INCR query requires ROW binlog enabled on base table.

How to Reproduce?

No response

Anything Else?

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[zclllyybb]

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

Initial analysis: this looks like a real FE error-message propagation bug, and the issue already has enough information for a targeted fix.

I checked the reported revision 49af19213e7 and the current local upstream/master ref. The intended semantic error already exists in fe/fe-core/src/main/java/org/apache/doris/nereids/rules/analysis/BindRelation.java: checkChangeScanCondition() throws AnalysisException("INCR query requires ROW binlog enabled on base table ...") when !olapTable.needRowBinlog().

However, makeOlapScan() constructs new RowBinlogTableWrapper((OlapTable) table) before calling checkChangeScanCondition(). That wrapper immediately calls originTable.getRowBinlogMeta().getSchema(). For a table created without row binlog, OlapTable.getRowBinlogMeta() first executes Preconditions.checkState(needRowBinlog()) without an error message. So the no-binlog case can fail earlier with an empty IllegalStateException, before the user-facing INCR query requires ROW binlog enabled on base table ... validation is reached.

The empty client result is consistent with the query planner catch path in StmtExecutor: the planner exception is wrapped through new AnalysisException(e.getMessage(), e), and a null exception message becomes an empty detail message in the final MySQL error packet.

Suggested fix:

1. In BindRelation.makeOlapScan(), validate the original OlapTable with checkChangeScanCondition((OlapTable) table, unboundRelation.getScanParams()) before constructing RowBinlogTableWrapper.
2. Reuse the returned StreamScanType after the scan is built, instead of recomputing it after wrapping.
3. Optionally add a defensive message to OlapTable.getRowBinlogMeta()'s checkState, but the main fix should avoid using RowBinlogTableWrapper before row-binlog support is confirmed.
4. Add a regression case for a duplicate-key table without binlog.enable=true / binlog.format=ROW, running:

SELECT k1, v1, __DORIS_BINLOG_OP__
FROM base_incr_no_binlog@incr("incrementType" = "DETAIL");

and assert that the error contains INCR query requires ROW binlog enabled on base table.

No additional issue information is required for the initial diagnosis. FE logs with the planner stack would only be useful as confirmation, not as a prerequisite for fixing this path.