github-actions[bot] commented on code in PR #61046:
URL: https://github.com/apache/doris/pull/61046#discussion_r2893408892
##########
fe/fe-core/src/main/java/org/apache/doris/load/routineload/RoutineLoadJob.java:
##########
@@ -1990,6 +1990,19 @@ public void gsonPostProcess() throws IOException {
CreateRoutineLoadCommand command = (CreateRoutineLoadCommand)
nereidsParser.parseSingle(
origStmt.originStmt);
CreateRoutineLoadInfo createRoutineLoadInfo =
command.getCreateRoutineLoadInfo();
+ // If tableId is set, resolve the current table name by ID so
that
+ // table rename / SWAP TABLE won't cause replay to fail with
stale name in origStmt.
+ if (!isMultiTable && tableId != 0) {
Review Comment:
Nit / suggestion (non-blocking): The same class of stale-name issue could
theoretically affect the **database name** when the original SQL used an
explicit db qualifier (e.g., `CREATE ROUTINE LOAD old_db.job_name ON table_name
...`). In that case, `LabelNameInfo.validate()` preserves the stale `old_db`
from `origStmt` instead of falling back to `ctx.getDatabase()`.
This is very unlikely in practice (database renames are rare, and most users
don't qualify the db name), but for completeness, a similar override could be
added:
```java
if (db != null) {
createRoutineLoadInfo.getLabelNameInfo().setDb(db.getName());
}
```
This would make the fix symmetric for both table name and database name
staleness. Feel free to defer to a follow-up if desired.
--
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]
