This isn't resettingresult, which isn't preserving the existing behavior
Actuallyresult is already reset at the top of the function, so it's not necessary in the other 2 places: lines 1297 and 1302

This is the point of interest of the PR right?
Since we're not usingExecuteTasksSynchronously here

TheReadIntoBufferAsyncTask is referencing theReadHead which is owned by theThriftFileTransport class.
That class has a method to clear the readheads:

voidClearPrefetch() {        ra_buffer.read_heads.clear();        ra_buffer.merge_set.clear();    }

If that's used, we'll have a dangling reference, so that needs to be looked into.

TheCachingFileHandle & is owned by theParquetReaderScanState (more on this below)

But from an even wider perspective, I'm not sure how we ensure that these dependencies that are mentioned are enforced? If this task dies, and the global/local state with it, everything in theReadIntoBufferAsyncTask is a dangling pointer to freed memory. How are we ensuring that's never the case?

^ If I remember correctly, we're blocking this task, and only once the other tasks have finished is this one unblocked right?
I think that should work,ClearPrefetch is only called by this Scan method, so that should never run until we're finished if we are in charge of unblocking this, and nothing else will ever cause a wake-up

Though I think it would be safer if we had an "outstanding prefetches" variable, so even if the task would erroneously wake up, we can detect and throw

The file transport seems to be owned byParquetReaderScanState

duckdb_base_std::unique_ptr<duckdb_apache::thrift::protocol::TProtocol> thrift_file_proto;

which is part of the local state for the table function:

structParquetReadLocalState :publicLocalTableFunctionState {ParquetReaderScanState scan_state;};

So we need to make sure that this local state will always outlive the createdReadIntoBufferAsyncTask tasks, or we need to wrap things in a shared ptr

I don't think we can guarantee that tasks are canceled in a specific order if an interrupt happens
So if the parquet read is cancelled before the prefetch tasks are cancelled, we'll be causing a heap-use-after-free

This is problematic for example:

voidExecutor::CancelTasks() {task.reset();{lock_guard<mutex>elock(executor_lock);// mark the query as cancelled so tasks will early-outcancelled =true;// destroy all pipelines, events and statesfor (auto &rec_cte_ref : recursive_ctes) {auto &rec_cte = rec_cte_ref.get().Cast<PhysicalRecursiveCTE>();rec_cte.recursive_meta_pipeline.reset();}pipelines.clear();root_pipelines.clear();to_be_rescheduled_tasks.clear();events.clear();}// Take all pending tasks and execute them until they cancelwhile (executor_tasks >0) {WorkOnTasks();}}

The blocked tasks are cleared first (to_be_rescheduled_tasks)
ThePipelineTask owns thePipelineExecutor
thePipelineExecutor owns theunique_ptr<LocalSourceState> local_source_state;

Thanks for the feedback!