Skip to content

test: leave the duration attribute out of the build-to-build comparison - #43

Merged
NaNIsaac merged 1 commit into
mainfrom
fix/duration-rounding
Oct 25, 2026
Merged

NaNIsaac merged 1 commit into
mainfrom
fix/duration-rounding

Conversation

@NaNIsaac

Copy link
Copy Markdown
Owner

Corrects the cause I gave in the issue text of #42 and fixes the flake in the test. Tier: low (tests only; nothing in src or rust/src changes).

Fixes #42.

What the issue got wrong: it said the Rust build truncates the command time to whole milliseconds while the Python build rounds it. That is true only of Python's shell-hook ingestion (commands/term.py, which reads $EPOCHREALTIME). cdg cap, which the test runs, measures in core/runner.py with int((time.monotonic() - started) * 1000), and Rust with started.elapsed().as_millis(): both truncate, so the two builds agree on how a given elapsed time is stored.

The flake is still real and has a different source: the test runs the command once with each build, and each run is timed separately. A command that takes about a millisecond (sh -c 'echo ...; exit 1' on a fast runner) can come out as 0 ms in one run and 1 ms in the other, and an entry with 0 ms has no duration attribute. Making Rust round would not remove this, only move the threshold to 0.5 ms.

  • normalise in rust/tests/capture_common/mod.rs now drops the duration="..." attribute instead of masking its value, so the comparison no longer depends on whether a run was fast enough to have one. stable() in the same test file already removes duration_ms from the stored JSON for the same reason.
  • New test a_command_that_took_under_a_millisecond_compares_equal_to_one_that_took_longer: the same <command> with no duration, 1ms and 1.5s normalise to one string.
  • Rendering of a stored duration is still covered by the unit test in rust/src/term.rs (duration="1.5s").

Tested locally on Windows: cargo fmt --check, cargo clippy --all-targets -- -D warnings, cargo test pass; cargo test --test cap -- --include-ignored with the Python build from uv sync --python 3.15 and CODIGEST_PARITY=1: 15 passed. The failure itself needs a Linux runner and a sub-millisecond run, so it was not reproduced here; the new test checks the comparison directly instead. The ubuntu parity job is the real check.

@NaNIsaac

Copy link
Copy Markdown
Owner Author

local-ci: b74b5e1 | ruff n/a (no Python change) | cargo fmt, clippy -D warnings and cargo test ok (cap parity with the Python build: 15 passed, Windows) | readme n/a

@NaNIsaac
NaNIsaac merged commit dca133a into main Oct 25, 2026
8 of 9 checks passed
@NaNIsaac
NaNIsaac deleted the fix/duration-rounding branch October 25, 2026 18:11
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.

Flaky parity test: duration attribute missing when the command takes under 1 ms

1 participant