[nextest-runner] allow replaying runs from pipes

[sunshowers]

This allows commands like cargo nextest run -R <(curl url) to work.

[codecov]

Codecov Report

❌ Patch coverage is 88.78049% with 23 lines in your changes missing coverage. Please review.
✅ Project coverage is 84.16%. Comparing base (b11af27) to head (357502c).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
nextest-runner/src/record/portable.rs	85.06%	23 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3071      +/-   ##
==========================================
+ Coverage   84.15%   84.16%   +0.01%     
==========================================
  Files         155      155              
  Lines       42021    42217     +196     
==========================================
+ Hits        35361    35531     +170     
- Misses       6660     6686      +26     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull request overview

This pull request enables nextest to replay test runs from pipes, particularly supporting process substitution like cargo nextest run -R <(curl url). The changes allow portable recordings to be read from non-seekable inputs (pipes, FIFOs) by detecting them and spooling the content to a temporary file when necessary.

Changes:

• Extended RunIdOrRecordingSelector parsing to recognize paths containing separators (not just .zip extensions)
• Added pipe detection and spooling logic in PortableRecording::open to handle non-seekable inputs
• Added GB support to SizeDisplay for better formatting of large file sizes

Reviewed changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
nextest-runner/src/record/run_id_index.rs	Enhanced parsing logic to treat strings with path separators (/ or \) as recording paths, enabling process substitution paths like /proc/self/fd/11 or /dev/fd/5
nextest-runner/src/record/portable.rs	Added ensure_seekable function to detect and handle non-seekable inputs by spooling to temp files with a 4 GiB safety limit
nextest-runner/src/errors.rs	Added new error types for seek probing failures, spool temp file errors, and spool size limit exceeded
nextest-runner/src/redact.rs	Extended SizeDisplay to format sizes >= 1 GB as "X.X GB" instead of "XXXX.X MB"
nextest-runner/src/record/snapshots/...snap	Updated snapshot test to reflect GB formatting
nextest-runner/src/record/AGENTS.md	Documented the new parsing logic and non-seekable input handling
integration-tests/tests/integration/record_replay.rs	Added comprehensive integration test with platform-specific named pipe implementations for both Unix and Windows
integration-tests/Cargo.toml	Added required Windows API features for named pipe support
cargo-nextest/src/dispatch/utility/store.rs	Updated help text to document process substitution support
cargo-nextest/src/dispatch/utility/debug.rs	Updated help text for extract-portable-recording command
cargo-nextest/src/dispatch/core/run.rs	Updated help text for --rerun option
cargo-nextest/src/dispatch/core/replay.rs	Updated help text for run_id argument
cargo-nextest/src/dispatch/core/tests.rs	Added test cases for process substitution paths

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The display_width calculation for GB may not account for rounding when the floating-point value rounds up to the next power of 10. For example, with a value close to 1000 GB (e.g., 999.95 GB), the integer part gb_int would be 999 (3 digits), but when formatted with .1 precision, it rounds to "1000.0 GB" which has 4 digits in the integer part. This would make the calculated width (3 + 2 + 3 = 8) not match the actual formatted string length (9 characters). The same issue exists for MB and KB display paths. Consider adding test cases for values near power-of-10 boundaries (e.g., 9.95 GB, 99.95 GB, 999.95 GB) to verify the width calculation handles rounding correctly.

[trunk-io]

     

View Full Report ↗︎ ⋅ Docs