github-actions[bot] commented on code in PR #67778:
URL: https://github.com/apache/doris/pull/67778#discussion_r3981197450
##########
be/src/load/channel/load_channel_mgr.cpp:
##########
@@ -88,6 +88,17 @@ Status LoadChannelMgr::open(const PTabletWriterOpenRequest&
params) {
if (it != _load_channels.end()) {
channel = it->second;
} else {
+ // Reordered/retried opens must not create a new generation behind
a
+ // live terminal record. A completed load can acknowledge a
duplicate
+ // open without creating writers; a failed load returns its first
error.
+ auto* handle = _load_state_channels->lookup(load_id.to_string());
+ if (handle != nullptr) {
+ auto* value =
static_cast<CacheValue*>(_load_state_channels->value(handle));
+ auto status =
+ value != nullptr ?
Status::Cancelled(value->_cancel_reason) : Status::OK();
+ _load_state_channels->release(handle);
+ return status;
Review Comment:
[P1] Preserve legitimate late incremental opens after local success
A null cache value does not prove that every later open is a duplicate. For
an auto-partition load on a BE with no initial node channel, an
incremental-only `TabletsChannel` counts only the senders that have discovered
it and does not use the hang fence. Sender A can therefore close the last
locally known channel while sender B is still running and later discovers a
partition on this BE. A's EOS stores this null success entry; B's incremental
open now returns `OK` here without creating any writers, and its first data
batch fails with an unknown load ID. The base implementation recreated the load
channel in this case. Please distinguish a retry of the completed open from a
new incremental open/generation, and add a multi-sender auto-partition test
where one sender finishes before another first opens this destination.
--
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]
