zclllyybb commented on issue #65309:
URL: https://github.com/apache/doris/issues/65309#issuecomment-4901433602
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:
```sql
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
