Skip to content

fix(cli): Defer zero-duration chunk adjustment#282

Open
leongdl wants to merge 1 commit into
OpenJobDescription:mainfrom
leongdl:fix/adaptive-zero-duration
Open

fix(cli): Defer zero-duration chunk adjustment#282
leongdl wants to merge 1 commit into
OpenJobDescription:mainfrom
leongdl:fix/adaptive-zero-duration

Conversation

@leongdl

@leongdl leongdl commented Jul 25, 2026

Copy link
Copy Markdown
Contributor

What was the problem/requirement? (What/Why)

Adaptive chunk sizing divides the cumulative task duration by the number of completed items. A task that completes below the clock's measurable resolution can produce a cumulative duration of 0.0. With a positive target runtime, the next calculation produces infinity, and converting that value to usize saturates to usize::MAX. The iterator then attempts to place the remaining parameter range into one enormous chunk.

Call stack

openjd run
  -> run::execute
  -> execution::execute
  -> run_workload
  -> execute_step
  -> execute_step_tasks
  -> execute_parameter_space_tasks
       -> RunContext::run_task
          -> Instant::elapsed().as_secs_f64()
       -> adjust_adaptive_chunk_size
          -> target_runtime_seconds / duration_per_task
          -> StepParameterSpaceIterator::set_chunks_default_task_count

What was the solution? (How)

Extract the numeric calculation into calculate_adaptive_chunk_size and defer adjustment when the cumulative duration is non-positive or non-finite. The iterator retains its current chunk size until a measurable timing sample is available, avoiding an arbitrary epsilon and preventing usize::MAX from being installed.

The existing conservative blend for the first ten completed items is unchanged for measurable durations. Focused unit tests cover both zero-duration deferral and normal early-sample blending.

What is the impact of this change?

Sub-clock-resolution tasks no longer cause adaptive execution to collapse the remaining range into a single giant chunk. Normal adaptive chunk sizing is unchanged. There is no public API change.

How was this change tested?

  • cargo test -p openjd-cli run::execution::tests — 2 passed
  • cargo test -p openjd-cli --test cli_tests — 152 passed
  • cargo test --workspace — passed
  • cargo clippy --all-features --all-targets --workspace -- -D warnings — passed
  • cargo fmt --all -- --check — passed
  • OpenJD 2023-09 conformance suite — 1,162 passed, 0 failed

Was this change documented?

Yes. specs/cli/run.md now documents that adaptive sizing waits for a measurable duration before changing the chunk size.

Is this a breaking change?

No.

Does this change impact security?

No.


By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Signed-off-by: David Leong <116610336+leongdl@users.noreply.github.com>
@leongdl
leongdl requested a review from a team as a code owner July 25, 2026 01:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant