test(interop): report why a spawned ros2 process failed

[YuanYuYuan]

Summary

The lyrical interop leg fails on every PR. The reason is currently impossible to read, because the test throws it away.

This makes the failure diagnosable. It does not fix lyrical.

Fixes #303's second half — the harness defect. The environment problem it exposes stays open there.

The defect

test_hiroz_add_two_ints_server_to_rcl_client spawns ros2 run demo_nodes_cpp add_two_ints_client with both streams sent to /dev/null, then asserts on its exit status. So a failure reports an exit code and nothing else:

Started process: RCL add_two_ints client
Stopping process group: RCL add_two_ints client
Process RCL add_two_ints client exited gracefully with status: ExitStatus(unix_wait_status(64000))

unix_wait_status(64000) is exit code 250, no signal, 23 ms after start, no output. ros2 run writes its reason to stderr — a missing executable, an unresolvable package, a library load failure all look identical here.

What this PR does

#	Change	Why
1	Pipe the client's stdout and stderr, and include both in the panic message on failure or timeout	ros2 run reports the cause on stderr
2	Drain both pipes on reader threads (OutputCapture in tests/common/mod.rs)	See below — this is the load-bearing part
3	fail-fast = false on the interop nextest profile	One environment problem is not evidence about the rest of the suite

Change 2 is why change 1 is safe. The streams were nulled deliberately, and the removed comment said so: "nothing reads it, and the try_wait loop below waits on the child's exit, which a full unread pipe would block." That objection is correct. Piping without draining would let a chatty child fill its pipe buffer and block, converting a fast failure into a 30-second timeout — a worse failure mode than the one being fixed. One reader thread per stream removes the coupling; they run until EOF, which arrives when the child exits.

On change 3: before this PR the leg reported 46/154 tests run — this single failure cancelled 108 tests. A leg that stops at the first external-process problem reports far less than its green counterpart, which is the same "green means less than it looks" shape as #276. The Evidence section below measures the result.

Evidence

Both changes are demonstrated by this PR's own CI run, on the lyrical leg that #303 tracks.

Change 1 and 2 — the cause is now printed. Where the leg previously reported only ExitStatus(unix_wait_status(64000)), it now reports:

--- child stdout ---
[ros2run]: Aborted
--- child stderr ---
double free or corruption (out)

That took #303 from "the client exits 250 and we cannot tell why" to a named failure mode in one run.

Change 3 — the suite is no longer erased by it. On the same leg:

	tests run	passed
before	46 / 154	45
after	139	138

The single environment failure was previously cancelling 108 tests. It now reports one failure and runs the rest, which also revealed that 8 of the 9 demo_nodes interop tests pass — the failure is confined to the hiroz-service → C++-client direction. That narrowing is recorded in #303 and is what makes it actionable.

Important

No failing baseline, and none is claimed. This is a diagnostics change: no test fails without it, and no test asserts on a panic message. Its justification is the two measurements above.

Check	Result
cargo check -p hiroz-tests --features ros-interop,jazzy --test demo_nodes	clean
cargo fmt	clean

The first compile check was run with --features ros-msgs,jazzy and passed vacuously — demo_nodes.rs is #![cfg(feature = "ros-interop")], so that build produced an empty binary. Only the ros-interop run above verifies anything.

What this does not do

• It does not fix lyrical — but it is what made the cause findable. The captured stderr turned an exit code into double free or corruption (out), which led to a valgrind trace naming rclcpp::ExecutorOptions::~ExecutorOptions() freeing a stack address, and from there to the real cause: the ROS image ships rclcpp 32.0.0 while the repository serves 32.0.2, so packages installed later are built against a different ABI. Nothing to do with hiroz or zenoh — it reproduces on a stock image with the default RMW. Diagnosis in lyrical interop: image ships rclcpp 32.0.0 while the repo ships 32.0.2, breaking ExecutorOptions ABI #303; fix in ci(interop): fix the lyrical ABI skew and make interop failures diagnosable #305.
• The four other Stdio::null() spawn sites in demo_nodes.rs are unchanged. None of them asserts on an exit status, so none can produce this failure mode. They can be converted if a future failure needs it.

Breaking changes

None. Test-harness only.