morningman opened a new issue, #70279: URL: https://github.com/apache/doris/issues/70279
### Search before asking - [x] I had searched in the [issues](https://github.com/apache/doris/issues?q=is%3Aissue) and found no similar issues. ### Version master @ 72e91896bbdd8760f8bd4e488e5672406b40ce52 (2026-11-03). The code paths below are unchanged on master as of 2026-11-05. ### What's Wrong? Before an `@incr` read, the FE builds a read fence and waits for transactions that can still land in the requested window. The two deployment modes report a timeout of that wait differently: - **Shared-storage, bounded reads:** the wait goes through `TSOService.waitForReadableWindow()`, which raises `ERR_INCR_VISIBLE_WAIT_TIMEOUT` (5101) or `ERR_INCR_WINDOW_NOT_READY` (5100) ([TimeBasedChangeVisibleWaiter.java#L184-L190](https://github.com/apache/doris/blob/72e91896bbdd8760f8bd4e488e5672406b40ce52/fe/fe-core/src/main/java/org/apache/doris/qe/TimeBasedChangeVisibleWaiter.java#L184-L190), [TSOService.java#L386](https://github.com/apache/doris/blob/72e91896bbdd8760f8bd4e488e5672406b40ce52/fe/fe-core/src/main/java/org/apache/doris/tso/TSOService.java#L386), [ErrorCode.java#L1239-L1243](https://github.com/apache/doris/blob/72e91896bbdd8760f8bd4e488e5672406b40ce52/fe/fe-common/src/main/java/org/apache/doris/common/ErrorCode.java#L1239-L1243)). - **Shared-nothing:** the FE drains earlier transactions with `waitForPreviousTransactions()` and `synchronizeClassicPublishers()`. On timeout these throw a plain `UserException`, for example `timeout waiting previous transactions finish for time-based read, ...`, with no error code ([#L196-L212](https://github.com/apache/doris/blob/72e91896bbdd8760f8bd4e488e5672406b40ce52/fe/fe-core/src/main/java/org/apache/doris/qe/TimeBasedChangeVisibleWaiter.java#L196-L212), [#L274-L299](https://github.com/apache/doris/blob/72e91896bbdd8760f8bd4e488e5672406b40ce52/fe/fe-core/src/main/java/org/apache/doris/qe/TimeBasedChangeVisibleWaiter.java#L274-L299), [#L318-L330](https://github.com/apache/doris/blob/72e91896bbdd8760f8bd4e488e5672406b40ce52/fe/fe-core/src/main/java/org/apache/doris/qe/TimeBasedChangeVisibleWaiter.java#L318-L330)). Clients therefore cannot recognize the shared-nothing timeout as "retry the same window". The Flink Doris Connector retries a window only when the error carries 5101 ([DorisFlightValueReader.java#L150-L172](https://github.com/apache/doris-flink-connector/blob/9550f9a0ebb16d95964ec65340f877b120f15403/flink-doris-connector/flink-doris-connector-base/src/main/java/org/apache/doris/flink/source/reader/DorisFlightValueReader.java#L150-L172)). In shared-nothing deployments, its `source.changelog.visible-wait-timeout` option has no effect, and a transient wait becomes a job failover. The shared-nothing drain also waits for earlier transactions that will commit after the window, such as a long-running load on the same table, so the timeout is easier to hit there. ### What You Expected? Visibility-wait timeouts report the same error code in both modes: 5101, or 5100 where the window is not ready. Clients can then handle them uniformly by retrying the same window. ### How to Reproduce? 1. In a shared-nothing cluster, create a changelog-enabled table. 2. Start a load on that table that stays open longer than `change_visible_timeout_ms`, for example a slow stream load. 3. While it runs, query `SELECT * FROM t@incr('startTimestamp' = '...', 'endTimestamp' = '<now>')`. 4. The query fails with the plain timeout message and no 5101 code, whereas the same situation on a shared-storage cluster returns 5101. ### Anything Else? Found by code reading while documenting the changelog features and the Flink incremental source; not yet reproduced on a cluster. ### Are you willing to submit PR? - [ ] Yes I am willing to submit a PR! ### Code of Conduct - [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- 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]
