turbo-tasks: prioritize recomputed tasks with Recomputation priority#93876
Open
sokra wants to merge 2 commits into
Open
turbo-tasks: prioritize recomputed tasks with Recomputation priority#93876sokra wants to merge 2 commits into
sokra wants to merge 2 commits into
Conversation
Adds a `Recomputation` variant to `TaskPriority` that sorts before all invalidation phases, ensuring recomputed tasks run first. Tasks invalidated during recomputation reset to `Initial` to prevent the recomputation order from spreading virally and breaking ordering.
sokra
force-pushed
the
sokra/recomputation-priority
branch
from
53c9d96 to
e1343eb
Compare
| @@ -1,21 +1,35 @@ | |||
| #[derive(Debug)] | |||
| pub enum TaskExecutionReason { | |||
| /// A root task was initially scheduled and is executed | |||
Contributor
There was a problem hiding this comment.
it isn't necessarily a 'root' task, right?
Contributor
There was a problem hiding this comment.
or is this the difference between Initial and ActivateInitial?
maybe this should be RootInitial?
| /// output yet), so it was scheduled and executed to produce the task output. | ||
| /// Or a task was called inside of a turbo_tasks::run closure for the first time (no output | ||
| /// yet), so it was scheduled and executed to produce the task output. | ||
| Connect, |
Contributor
There was a problem hiding this comment.
this one is kind of confusing to me... this could be a new root task connecting a child?
but how is that different from Initial. i see that this is set if a child is connected with no parent, so isn't that limited to root tasks
lukesandberg
approved these changes
May 15, 2026
Contributor
Stats from current PR✅ No significant changes detected📊 All Metrics📖 Metrics GlossaryDev Server Metrics:
Build Metrics:
Change Thresholds:
⚡ Dev Server
📦 Dev Server (Webpack) (Legacy)📦 Dev Server (Webpack)
⚡ Production Builds
📦 Production Builds (Webpack) (Legacy)📦 Production Builds (Webpack)
📦 Bundle SizesBundle Sizes⚡ TurbopackClient Main Bundles
Server Middleware
Build DetailsBuild Manifests
📦 WebpackClient Main Bundles
Polyfills
Pages
Server Edge SSR
Middleware
Build DetailsBuild Manifests
Build Cache
🔄 Shared (bundler-independent)Runtimes
📎 Tarball URLCommit: e1343eb |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What?
Introduces a new
Recomputationpriority inTaskPrioritythat schedules recomputed tasks (tasks re-run because their output or cell wasn't available when read) ahead of all invalidation phases. Also documents everyTaskExecutionReasonvariant and removes the unusedLocalvariant.Why?
When a task is recomputed because a downstream consumer needed its output/cell, that recomputation should run before lower-priority invalidations so the consumer can make progress. Previously these recomputations were scheduled with
Initialpriority, which placed them alongside fresh work and behind ongoing invalidation phases, hurting latency for the task actually being awaited.Care is needed so the new priority doesn't spread virally: any invalidation triggered during a
Recomputationtask must not itself be taggedRecomputation, otherwise the priority would leak across the graph and break ordering. The change therefore resets the priority toInitialfor invalidations triggered from a recomputation context.How?
turbo-tasks/src/manager.rs: AddTaskPriority::Recomputationvariant, ordered beforeInvalidation. UpdateDisplayandupdateimpls.turbo-tasks-backend/src/backend/mod.rs: Schedule output-not-available and cell-not-available recomputations withTaskPriority::Recomputationinstead ofInitial.turbo-tasks-backend/src/backend/operation/invalidate.rs: Whenmake_task_dirty_internalruns under a parent task withRecomputationpriority, downgrade the propagated priority toInitialso the recomputation marker does not spread. Also tighten the "already dirty" branch so a storedInitialpriority is always replaced by a more specific parent priority.turbo-tasks/src/task_execution_reason.rs: Document each variant and drop the unusedLocalvariant (and itsas_strarm).Closes NEXT-