feat(parity): stream progress, journal every result, resume after interruption - #7436
Conversation
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe parity runner adds durable JSONL journaling, resumable execution, selection-aware progress, torn-line recovery, interruption handling, and journal-based report reconstruction. Tests cover fresh runs, resumed runs, report equivalence, runtime changes, and process cleanup. ChangesParity streaming and resume
Estimated code review effort: 4 (Complex) | ~45 minutes Possibly related PRs
Suggested labels: Suggested reviewers: ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
A full sweep reached 4h34m with zero visible output today, and an interruption at any point would have lost all of it. Results were accumulated in a bash array and serialized once, at the very end.
One mechanism, both properties
record_result()was already the single choke point every result path funnels through. It now appends one JSONL line as each test completes, and emits the progress line from the same call — so the checkpoint and the progress signal are the same write.[142/1178] (01:12:33) test_gap_foo … PASSon stderr. stdout is untouched becauserun_module_parity.shscrapes the summary from a2>&1capture withawk -F': *'. The[i/N]denominator required moving--filter/--shardinto a selection pre-pass; shard arithmetic and ordering unchanged.test-parity/reports/journal/parity_<selection>.jsonl, keyed by suite/module/filter/shard so the 8 conformance shards never share a file. A write failure is fatal rather than silently dropping results — the realistic cause is a full disk, and this box hit 11 GiB today.perryandlibperry_runtime.a/libperry_stdlib.a, plus selection flags and platform. Content hash, not mtime — mtime's failure mode (binary swapped in place, compares equal) is the unsafe direction, and a stale archive changes behaviour whileperryis untouched.latest.json: that feeds the gap/threshold/matrix gates, and a partial sweep read as complete would move a gate on tests that never ran.Two bugs found while testing it
1. A torn final line swallowed the next record.
kill -9mid-write leaves a newline-less line; the next append concatenated onto it, making both unparseable — silently losing a second, innocent test. Caught because results came back01,02,04,03,…. Fixed by sealing with a newline before appending.2.
tests/test_parity_build_reuse.sh's assertions were inert on macOS. A standalone failing[[ ]]does not tripset -eunder bash 3.2 — verified directly:Every
[[ ]]in that file, including pre-existing ones, could not fail a run on a Mac. Converting to explicit|| failimmediately surfaced a real header/grep mismatch.Verification
latest.jsonwithheld, resumes at[3/8], report identical; also process-group SIGINT and a real-compiler SIGTERM at 6/12kill -9+ resume--filter; control still resumesorigin/mainover the same filter; both exit 0;run_gap_tests.shwrapper unaffectedbash -n/ shellcheckorigin/mainEach check was verified capable of failing — four mutations (unseal the torn line, drop
toolchainfrom the identity check, disable streaming, journal only at the end) each turn the suite red.Left alone
known_failures.jsonhandling,normalize_output, the 80% threshold, and the report emitter — the arrays it consumes are rebuilt from the journal rather than rewriting it, because the format has downstream-depended-upon quirks (the[""]-for-empty-failure-list thatrun_gap_tests.shfilters). Byte-identical output proves the equivalence.Summary by CodeRabbit
New Features
Tests