fix(exec-harness): reject negative and non-finite numeric durations - #528
Open
mohamedAtoui wants to merge 1 commit into
Open
fix(exec-harness): reject negative and non-finite numeric durations#528mohamedAtoui wants to merge 1 commit into
mohamedAtoui wants to merge 1 commit into
Conversation
Greptile SummaryThis PR tightens wall-time duration validation before converting numeric seconds to nanoseconds.
Confidence Score: 5/5The PR appears safe to merge; the new validation rejects the targeted invalid inputs while preserving documented zero-duration semantics. No actionable failures remain: the guard runs before the saturating cast, the production argument-conversion path propagates the validation error, and tests cover rejected values plus
|
| Filename | Overview |
|---|---|
| crates/exec-harness/src/walltime/config.rs | Adds correct finite/non-negative validation and focused regression tests without changing valid duration behavior. |
Reviews (1): Last reviewed commit: "fix(exec-harness): reject negative and n..." | Re-trigger Greptile
mohamedAtoui
force-pushed
the
fix/reject-negative-durations
branch
from
September 5, 2026 13:11
491f788 to
0e511c3
Compare
Bare numeric durations were parsed as f64 and converted with a saturating `as u64` cast, so `-1` and `NaN` became 0 and `inf` became u64::MAX. A `--max-time -1` therefore ran warmup and only failed later with "Unable to determine number of rounds to perform". Build the duration with `Duration::try_from_secs_f64`, which rejects those values, and share the nanosecond conversion with the humantime branch. Humantime inputs such as `-1s` were already rejected. `0` stays valid since it is how warmup is disabled. Fixes CodSpeedHQ#364
mohamedAtoui
force-pushed
the
fix/reject-negative-durations
branch
from
September 5, 2026 13:19
0e511c3 to
d08edb0
Compare
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
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.
Fixes #364.
Bare numeric walltime durations were parsed with
f64::from_strand converted with a saturatingas u64cast. That silently turned-1,-0.5andNaNinto0, andinfintou64::MAX. Since amax_timeof0means "unlimited",--max-time -1ran the warmup phase and only failed afterwards withUnable to determine number of rounds to perform.The numeric branch now builds a
DurationwithDuration::try_from_secs_f64, which already rejects negative, NaN and infinite values, and both branches share the single nanosecond conversion at the end. The error surfaces during argument validation, with the standard library explaining the cause:Humantime inputs such as
-1swere already rejected byhumantime::parse_duration, so that branch is unchanged.Note for reviewers:
-0parses as-0.0, whichtry_from_secs_f64accepts, so it stays valid and yields0. That is intentional,0is the documented way to disable warmup, and it is covered by a test.Adds unit tests for the rejected values, for
0/-0remaining valid, and one covering the reported--max-time -1path end to end.