Why SharedQuery and ResultQueue need to be cancelled explicitly in PipelineExecutorContext::cancel, but this don't need to be cancelled in PipelineExecutorContext::cancel?

Because it will not be stuck forever, when the query is canceled, checkCancel will always be called, because wait_for_notify must be because the queue is empty. When the queue is empty, it will trigger an asynchronous load bucket event, and the load bucket event will call checkCancel.

If trigger an asynchronous load bucket event fails, will it still work?

yes, Event::finishImpl is always called, regardless of failure or cancellation

OK. I want to confirm another unrelated question here, why WorkQueue in this pr don't need to be cancelled explicitly in PipelineExecutorContext::cancel?

When query meet error, the storage layer is not informed?

Yes, the storage layer is not explicitly canceled.

However, the query will not be stuck, because the storage layer will continuously generate blocks, which will trigger checkCancel, thus ending the query.

Storage layer generate block => pipeline task is notified and finishes since it found the query is cancelled => ~UnorderedSourceOp() is called, and in side ~UnorderedSourceOp(), it will call task_pool->decreaseUnorderedInputStreamRefCount(), which eventually stop the storage read?

Storage layer generate block => pipeline task is notified and finishes since it found the query is cancelled => ~UnorderedSourceOp() is called, and in side ~UnorderedSourceOp(), it will call task_pool->decreaseUnorderedInputStreamRefCount(), which eventually stop the storage read?

yes