HappenLee commented on code in PR #67261:
URL: https://github.com/apache/doris/pull/67261#discussion_r3878367122
##########
be/src/exec/pipeline/pipeline_fragment_context.cpp:
##########
@@ -209,13 +209,32 @@ bool PipelineFragmentContext::notify_close() {
// Method like exchange sink buffer will call query ctx cancel. If we add lock
here
// There maybe dead lock.
void PipelineFragmentContext::cancel(const Status reason) {
+ if (notify_close()) {
+ return;
+ }
+ auto expected = LifecycleState::CREATED;
+ if (!_lifecycle_state.compare_exchange_strong(expected,
LifecycleState::CANCELLING,
Review Comment:
I do not think this is a blocking correctness issue. The intended ordering
point here is the lifecycle transition when the last task has drained, rather
than entry into cancel() or the earlier notify_close() observation.
All task-originated failures are published before a task is counted as
closed: TaskScheduler::close_task() calls ctx->cancel() for
execute/close/finalize errors before decrement_running_task(). Therefore, final
close cannot overtake an unpublished task execution failure.
The direct report-pool callback is a different case. If its cancellation
overlaps the last task completion, allowing the last-task close to win is
intentional: once _closed_tasks reaches _total_tasks, the PFC has no unfinished
execution to cancel. CANCELLING elects the owner of per-fragment cancellation
diagnostics and side effects; it is not a publication barrier that requires
final close to wait. The final report snapshots QueryContext status at the
close linearization point, and a late control-plane report failure does not
retroactively invalidate the completed fragment.
For the same reason, the current test joins cancellation threads before
close intentionally: it verifies single-winner cancellation side effects and
one-shot close. An overlap test would have to allow either operation to win and
would not establish that cancellation must take precedence.
--
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]
