A diagnostic's path is cut short on macOS, contradicting the no-break-words handler, and it flakes the run-lock test that gates releases

[vjovanov]

Problem

e2e::headless_recovery_tests::a_child_that_loses_the_run_lock_fails_fast_with_the_lock_diagnostic failed once on cargo test (macos-latest), on main at 901d4152d3, run 33297725065 attempt 1. It passed on the PR run for the same tree and on the re-run, so it is intermittent.

It matters more than an ordinary flake: auto-bump.yml gates on "CI on current main tip is green", so a failure here blocks the release, which is how it was found.

What the diagnostic actually showed

The assertion that failed is message.contains("run.lock") (crates/rhei-cli/tests/e2e/headless_recovery_tests.rs:307). The preceding contains("already live") passed. Full captured message:

  × the run exited before it started (exit status 1):
  │     × a run is already live on
  │     │
  │ /private/var/folders/df/djsxfhc17x95674wsm_g8s980000gn/T/rhei-integ-headless-childlock-1788
  │   Pass 1: 2 ready, 0 terminal, 2 total.
  │   Ready: Task plan.1: First, Task plan.2: Second
  │   Deferred 1 task(s) in non-concurrent states to a later pass: plan.2
  │   Spawning program for Task plan.1: First
  │     Log:
  │ /private/var/folders/df/djsxfhc17x95674wsm_g8s980000gn/T/rhei-integ-headless-childlock-1788072571224528000/runtime/logs/task-plan.1-pending.log
  help: the run's console is at
        /var/folders/df/djsxfhc17x95674wsm_g8s980000gn/T/rhei-integ-headless-childlock-1788072571224528000/runtime/run.log

The already live on path stops at childlock-1788. The real directory is childlock-1788072571224528000, so the path is cut before it ever reaches /runtime/run.lock — which is why the assertion failed.

The cut is the interesting part, and it is not a plain width truncation: the Log: path four lines below is 145 characters and prints in full. Only the miette-rendered line is short; the lines carrying the child's captured stdout are intact.

Why this looks like a product defect, not a test defect

install_diagnostic_handler (crates/rhei-cli/src/cli/cli_dispatch.rs:156-166) configures miette with break_words(false), WordSeparator::AsciiSpace and WordSplitter::NoHyphenation specifically so this cannot happen. Its doc comment states the intent:

miette's defaults offer a break opportunity at every hyphen and every /, and split an overlong token outright. All three land mid-path on the filesystem diagnostics this CLI prints constantly, and a path broken across lines cannot be copied, clicked, or grepped. Treating only spaces as break points keeps prose wrapping while a long path overflows the wrap column intact.

A path that arrives cut short contradicts that guarantee. If it can happen in a test it can happen to a user, and the failure mode is worse there: the diagnostic names a lock file the reader cannot find, on the platform whose temporary directories are deepest.

Not reproduced locally

Linux, cargo test --test integration a_child_that_loses_the_run_lock, with TMPDIR set to a 186-character path mimicking the macOS shape: passes, path intact. So the trigger involves something beyond path length — plausibly the width miette resolves in that environment, or an interaction with break_words(false) when a single token exceeds the wrap column.

Deliberately not "fixed" by loosening the assertion. The test is asserting the thing the handler promises, and weakening it would hide the defect rather than close it.

Expected

1. Determine why the rendered path is cut when break_words(false) is set, and make the guarantee in install_diagnostic_handler hold — a path in a diagnostic is never shortened.
2. Once it holds, the existing assertion passes on every platform with no change.

Found while releasing 0.3.1.