Skip to content

feat: short-circuit ContinuedTask.Scheduler.canTake when no continued tasks are buildable#564

Open
eleanorgoh wants to merge 1 commit into
jenkinsci:masterfrom
eleanorgoh:feature/continued-task-fast-path
Open

feat: short-circuit ContinuedTask.Scheduler.canTake when no continued tasks are buildable#564
eleanorgoh wants to merge 1 commit into
jenkinsci:masterfrom
eleanorgoh:feature/continued-task-fast-path

Conversation

@eleanorgoh
Copy link
Copy Markdown

@eleanorgoh eleanorgoh commented May 29, 2026

Track the number of buildable ContinuedTask items via a QueueListener so the QueueTaskDispatcher hot path can return immediately in the common case where no continued task is queued, instead of allocating a fresh buildable-items copy and scanning it on every (node × item) candidate pair per maintain pass.

The counter is tracked on instanceof ContinuedTask (stable over the buildable lifecycle) rather than the dynamic isContinued() value, so drift is impossible in the increment/decrement direction. An @Initializer reconciles the counter after JOB_LOADED to cover items restored from queue.xml at startup (the exact case ContinuedTask exists for). Any missed callback would only cause the fast path to miss and fall through to the original scan — correctness is preserved.

We're trying to solve for #560.
A performance improvement in the spirit of #563.

Testing done

Includes unit tests.

Submitter checklist

  • Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
  • Ensure that the pull request title represents the desired changelog entry
  • Please describe what you did
  • Link to relevant issues in GitHub or Jira
  • Link to relevant pull requests, esp. upstream and downstream changes
  • Ensure you have provided tests that demonstrate the feature works or the issue is fixed

… are buildable

Track the number of buildable ContinuedTask items via a QueueListener so the
QueueTaskDispatcher hot path can return immediately in the common case where
no continued task is queued, instead of allocating a fresh buildable-items
copy and scanning it on every (node × item) candidate pair per maintain pass.

The counter is tracked on instanceof ContinuedTask (stable over the buildable
lifecycle) rather than the dynamic isContinued() value, so drift is impossible
in the increment/decrement direction. An @Initializer reconciles the counter
after JOB_LOADED to cover items restored from queue.xml at startup (the exact
case ContinuedTask exists for). Any missed callback would only cause the fast
path to miss and fall through to the original scan — correctness is preserved.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@eleanorgoh eleanorgoh force-pushed the feature/continued-task-fast-path branch from 3646c4b to ff1703b Compare May 29, 2026 18:25
@eleanorgoh eleanorgoh marked this pull request as ready for review May 29, 2026 20:37
@eleanorgoh eleanorgoh requested a review from a team as a code owner May 29, 2026 20:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant