Skip to content

Fix "Task polled after completion" panic - #60693

Merged
Veykril merged 1 commit into
mainfrom
task-polled-after-completion
Jul 9, 2026
Merged

Fix "Task polled after completion" panic#60693
Veykril merged 1 commit into
mainfrom
task-polled-after-completion

Conversation

@reflectronic

Copy link
Copy Markdown
Member

Dropping a scheduled runnable cancels its task and makes the next poll of any awaiter panic with "Task polled after completion." The only paths where we drop these runnables seem to be during shutdown or extreme resource exhaustion, so, let's leak the runnables instead of crashing.

On Windows, we also moved to calling the Win32 thread pool API directly, because 1) WinRT thread pool API is just a wrapper that adds overhead we don't need, and 2) the closure we pass to the WorkItemHandler object takes ownership of the runnable object, so if the WinRT thread pool releases the delegate, it can free the runnable without our control.

Release Notes:

  • N/A

@cla-bot cla-bot Bot added the cla-signed The user has signed the Contributor License Agreement label Jul 9, 2026
@zed-community-bot zed-community-bot Bot added the staff Pull requests authored by a current member of Zed staff label Jul 9, 2026
@Veykril
Veykril added this pull request to the merge queue Jul 9, 2026
Merged via the queue into main with commit 2c4e447 Jul 9, 2026
48 checks passed
@Veykril
Veykril deleted the task-polled-after-completion branch July 9, 2026 18:09
@Veykril

Veykril commented Jul 13, 2026

Copy link
Copy Markdown
Member

/cherry-pick preview

zed-zippy Bot added a commit that referenced this pull request Jul 13, 2026
…view) (#60886)

Cherry-pick of #60693 to preview

----
Dropping a scheduled runnable cancels its task and makes the next poll
of any awaiter panic with "Task polled after completion." The only paths
where we drop these runnables seem to be during shutdown or extreme
resource exhaustion, so, let's leak the runnables instead of crashing.

On Windows, we also moved to calling the Win32 thread pool API directly,
because 1) WinRT thread pool API is just a wrapper that adds overhead we
don't need, and 2) the closure we pass to the `WorkItemHandler` object
takes ownership of the runnable object, so if the WinRT thread pool
releases the delegate, it can free the runnable without our control.

Release Notes:

- N/A

Co-authored-by: John Tur <john-tur@outlook.com>
eholk added a commit that referenced this pull request Jul 14, 2026
…ble) (#60935)

Cherry-pick of #60693 to stable

----
Dropping a scheduled runnable cancels its task and makes the next poll
of any awaiter panic with "Task polled after completion." The only paths
where we drop these runnables seem to be during shutdown or extreme
resource exhaustion, so, let's leak the runnables instead of crashing.

On Windows, we also moved to calling the Win32 thread pool API directly,
because 1) WinRT thread pool API is just a wrapper that adds overhead we
don't need, and 2) the closure we pass to the `WorkItemHandler` object
takes ownership of the runnable object, so if the WinRT thread pool
releases the delegate, it can free the runnable without our control.

Release Notes:

- N/A

Co-authored-by: John Tur <john-tur@outlook.com>
jolutz pushed a commit to jolutz/zed that referenced this pull request Aug 8, 2026
…ry-pick to preview) (zed-industries#60886)

Cherry-pick of zed-industries#60693 to preview

----
Dropping a scheduled runnable cancels its task and makes the next poll
of any awaiter panic with "Task polled after completion." The only paths
where we drop these runnables seem to be during shutdown or extreme
resource exhaustion, so, let's leak the runnables instead of crashing.

On Windows, we also moved to calling the Win32 thread pool API directly,
because 1) WinRT thread pool API is just a wrapper that adds overhead we
don't need, and 2) the closure we pass to the `WorkItemHandler` object
takes ownership of the runnable object, so if the WinRT thread pool
releases the delegate, it can free the runnable without our control.

Release Notes:

- N/A

Co-authored-by: John Tur <john-tur@outlook.com>
jolutz pushed a commit to jolutz/zed that referenced this pull request Aug 8, 2026
Dropping a scheduled runnable cancels its task and makes the next poll
of any awaiter panic with "Task polled after completion." The only paths
where we drop these runnables seem to be during shutdown or extreme
resource exhaustion, so, let's leak the runnables instead of crashing.

On Windows, we also moved to calling the Win32 thread pool API directly,
because 1) WinRT thread pool API is just a wrapper that adds overhead we
don't need, and 2) the closure we pass to the `WorkItemHandler` object
takes ownership of the runnable object, so if the WinRT thread pool
releases the delegate, it can free the runnable without our control.

Release Notes:

- N/A
playdohface pushed a commit to playdohface/zed that referenced this pull request Aug 29, 2026
Dropping a scheduled runnable cancels its task and makes the next poll
of any awaiter panic with "Task polled after completion." The only paths
where we drop these runnables seem to be during shutdown or extreme
resource exhaustion, so, let's leak the runnables instead of crashing.

On Windows, we also moved to calling the Win32 thread pool API directly,
because 1) WinRT thread pool API is just a wrapper that adds overhead we
don't need, and 2) the closure we pass to the `WorkItemHandler` object
takes ownership of the runnable object, so if the WinRT thread pool
releases the delegate, it can free the runnable without our control.

Release Notes:

- N/A
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cla-signed The user has signed the Contributor License Agreement staff Pull requests authored by a current member of Zed staff

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants