fix(cli): reject an invalid output id in dora record --proxy instead of panicking

[phil-opp]

🤖 Machine-generated PR. Opened by Claude Code as part of an automated codebase review. Please review carefully before merging.

Issue

dora record --proxy subscribes to the (node, output) pairs found by discover_descriptor_outputs. That function walks the untyped YAML and accepts any string. The typed parse is deliberately non-fatal.

The two ids were converted differently:

• The node id went through the fallible parse::<NodeId>().
• The output id was converted with .into(), i.e. DataId's From<String>, which panics on an invalid id (see its doc in libraries/message/src/id.rs).

A descriptor with outputs: ["bad id"], "a//b" or a leading / therefore crashed the recorder with invalid DataId 'bad id' instead of returning an error.

Fix

Parse both ids fallibly in a small helper, parse_ws_topics, and return invalid output ID in topic: …. Operator outputs such as op/out are still accepted.

Validation

Class: B

• New test invalid_output_id_in_proxy_topics_is_an_error_not_a_panic: the three invalid forms return Err, and op/out parses.
• cargo test -p dora-cli --lib record: ✅ (28 passed)
• cargo clippy -p dora-cli --all-targets -- -D warnings: ✅, cargo fmt --check: ✅

🤖 Generated with Claude Code

https://claude.ai/code/session_016ZqAqLhDyZGTnpGHyENnh7

---

Generated by Claude Code

[trunk-io]

Merging to main in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[phil-opp]

CI note: Audit fails on main's yanked yoke-derive 0.8.3, not because of this PR. I've cherry-picked the fix from #3682 (Cargo.lock → 0.8.4); it becomes a no-op once that lands.

---

Generated by Claude Code

[phil-opp]

🤖 Automated review (fully automated Claude Code review; no human checked it)

No issues found.

• The bug is real on main. o.clone().into() (binaries/cli/src/command/record.rs:564) goes through DataId::from(String), which panics on an invalid id. The untyped YAML walk can produce such an id, because the typed descriptor parse is non-fatal.
• The fix is right. Switching to the fallible parse::<DataId>() fixes it. I found no other place in the CLI that converts a user string into a DataId with .into().
• The test covers the important cases. It checks the panic cases ("bad id", "a//b", "/out") and a valid operator-qualified id. It can't compile on main because parse_ws_topics is new there, but the panic it guards against follows directly from the From<String> impl.

---

Generated by Claude Code