[Bug] Table-level CCR silently ignores upstream DROP TABLE

[Ryan19929]

Problem

在表级 CCR 任务中，上游执行

DROP TABLE db.tbl;

下游既无 WARN 也无 ERROR，任务只是继续轮询最新位点，什么都没发生。这种静默跳过不符合预期（希望看到一条警告或明确报错）。

Root-Cause

组件	代码位置	行为说明
FE	org.apache.doris.persist.EditLog.addBinlog()	DROP_TABLE 事件仅写入库级元数据 droppedTables，随后提前 return，不会进入表级 binlog 列表。
CCR	DropTableHandle.Handle()	已存在判断分支： if j.SyncType != ccr.DBSync { return error … } 但由于 FE 未下发任何表级 binlog，该分支永远不被触发。

Proposed Fix

1. FE – 扩展 getBinlog() 接口

public Pair<TStatus, List<TBinlog>> getBinlog(long tableId, long prevCommitSeq, long numAcquired) {
    ...
    if (isTableDropped(tableId)) {
        LOG.warn("table is dropped, return BINLOG_NOT_FOUND_TABLE. tableId: {}", tableId);
        status.setStatusCode(TStatusCode.BINLOG_NOT_FOUND_TABLE);
        return Pair.of(status, null);
    }
    ...
}
private boolean isTableDropped(long tableId) {
    return droppedTables.stream().anyMatch(pair -> pair.first.equals(tableId));
}

2. CCR – 捕获并处理错误码

if err.Code == BINLOG_NOT_FOUND_TABLE
    log.Warn("upstream table dropped, stopping table-sync job")
    j.Pause()  // or fail-fast, depending on policy
}

同名表重建场景

上游执行

DROP TABLE db.tbl;
CREATE TABLE db.tbl (...);  -- 新 table-id

CCR 仍停留在 TABLE_NOT_FOUND 状态，不会自动恢复同步。
在我们的使用场景中，希望表级别任务新增对「同名新表 」的检测，上游表重建后自动重启同步任务。CCR考虑支持这个功能吗？这边可以提交 PR。

[w41ter]

在我们的使用场景中，希望表级别任务新增对「同名新表 」的检测，上游表重建后自动重启同步任务。CCR考虑支持这个功能吗？这边可以提交 PR。

可以的。建议增加一个选项用来控制行为：默认情况下，遇到问题后调用 Pause，并提供一个 msg 供用户参考；当该选项设置了，就尝试重建表，并自动重启同步任务。

@Ryan19929 你看看怎么样？

[Ryan19929]

嗯嗯，让用户选择比较合适，我到时候提一个pr