Bug report
What did you do?
Run a fresh new-architecture changefeed from PR #5956 with scan window enabled, eventual redo, four hot tables, and two idle tables that have no commits after the changefeed start-ts.
What did you expect to see?
Idle-table dispatchers should advance their resolved-ts directly to the EventStore and SchemaStore frontier because there is no data to scan. They should not pin the global scan-window base or changefeed checkpoint.
What did you see instead?
The two idle-table normal dispatchers stayed near the changefeed start checkpoint while their received resolved-ts moved forward. getScanTaskRequestResult first caps CommitTsEnd by the global scan window and then, even after proving there are no DML or DDL events in the range, sends only that capped boundary.
When memory pressure shrinks the redo scan window to one second, an idle dispatcher can advance at no more than one second per one-second controller tick. Any accumulated lag therefore cannot be recovered, the idle dispatcher continues pinning the shared base, and the changefeed checkpoint can remain minutes behind despite no writes to that table.
Proposed fix
When EventStore and SchemaStore frontiers prove the entire pre-window range contains no DML or DDL, send the pre-window resolved boundary directly. Keep scan-window capping unchanged whenever the range may contain an event, and preserve syncpoint ordering through the existing sendResolvedTs path.
This issue is a follow-up to #6037 and the scan-window investigation around PR #5956.
Bug report
What did you do?
Run a fresh new-architecture changefeed from PR #5956 with scan window enabled, eventual redo, four hot tables, and two idle tables that have no commits after the changefeed start-ts.
What did you expect to see?
Idle-table dispatchers should advance their resolved-ts directly to the EventStore and SchemaStore frontier because there is no data to scan. They should not pin the global scan-window base or changefeed checkpoint.
What did you see instead?
The two idle-table normal dispatchers stayed near the changefeed start checkpoint while their received resolved-ts moved forward. getScanTaskRequestResult first caps CommitTsEnd by the global scan window and then, even after proving there are no DML or DDL events in the range, sends only that capped boundary.
When memory pressure shrinks the redo scan window to one second, an idle dispatcher can advance at no more than one second per one-second controller tick. Any accumulated lag therefore cannot be recovered, the idle dispatcher continues pinning the shared base, and the changefeed checkpoint can remain minutes behind despite no writes to that table.
Proposed fix
When EventStore and SchemaStore frontiers prove the entire pre-window range contains no DML or DDL, send the pre-window resolved boundary directly. Keep scan-window capping unchanged whenever the range may contain an event, and preserve syncpoint ordering through the existing sendResolvedTs path.
This issue is a follow-up to #6037 and the scan-window investigation around PR #5956.