morningman opened a new issue, #70280: URL: https://github.com/apache/doris/issues/70280
### 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? #67820 describes the intended handling of uncertain commits: "On `KV_TXN_MAYBE_COMMITTED`, an RPC timeout, connection loss or another uncertain result, synchronously advance the per-instance Meta Service fence to the attempted TSO before removing it. If fencing fails, deactivate the TSO service so reads and allocations cannot use an unsafe prefix." In `CloudGlobalTransactionMgr.commitTxn`, only the exception path does this, by calling `fenceAndAbandonCommitTso()` ([CloudGlobalTransactionMgr.java#L951-L962](https://github.com/apache/doris/blob/72e91896bbdd8760f8bd4e488e5672406b40ce52/fe/fe-core/src/main/java/org/apache/doris/cloud/transaction/CloudGlobalTransactionMgr.java#L951-L962)). When Meta Service returns `KV_TXN_MAYBE_COMMITTED` as a response code, the FE calls `abandonCommitTso()`, which removes the TSO from the tracker without advancing the fence ([#L965-L977](https://github.com/apache/doris/blob/72e91896bbdd8760f8bd4e488e5672406b40ce52/fe/fe-core/src/main/java/org/apache/doris/cloud/transaction/CloudGlobalTransactionMgr.java#L965-L977)). Suspected consequence: once the TSO leaves the tracker, bounded `@incr` reads and Table Stream reads stop waiting for it. If the uncertain commit takes effect afterwards with that TSO, nothing rejects it, because the fence was not advanced. A reader whose window has already passed that TSO then misses the change permanently. ### What You Expected? `KV_TXN_MAYBE_COMMITTED` is handled like the other uncertain outcomes: advance the fence to the attempted TSO before releasing it, and deactivate the TSO service if fencing fails, as described in #67820. If the current behavior is intentional, please document why the response-code case is safe. ### How to Reproduce? 1. Inject a `KV_TXN_MAYBE_COMMITTED` response from Meta Service for a commit on a changelog-enabled table, for example via fault injection in `commit_txn`. 2. Observe that the Meta Service TSO fence is not advanced to the attempted TSO, while the TSO is removed from `TSOTransactionTracker`. ### Anything Else? Found by code reading while documenting the changelog and TSO design; not reproduced. Whether a maybe-committed transaction can still take effect after the FE receives the response depends on Meta Service and FoundationDB semantics, so please confirm the impact. ### 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]
