Location
src/bin/main.rs — cmd_send and cmd_subscribe, each constructing its own VirtualBus::new(); README.md quickstart section presenting rust-lin send / rust-lin subscribe as a usable pair.
Problem
Each CLI subcommand instantiates a brand-new, independent VirtualBus. subscribe therefore listens on a bus that no other process (or even any other invocation of the same binary) ever publishes to — it will simply block indefinitely waiting for frames that can never arrive. send publishes to a bus that's dropped the moment the process exits, so nothing it wrote is ever visible anywhere else. The README's quickstart walks through running rust-lin send … and rust-lin subscribe … as if they communicate with each other, but as two separate CLI invocations they never share any transport, so that workflow can't actually work as documented.
Suggested fix
Either make the README explicit that the in-process virtual bus can't bridge two separate CLI invocations (i.e. these are demo/smoke-test commands, not a real pub/sub pipe), or back the CLI with an actual shared transport (a local socket, named pipe, or similar) so send/subscribe can genuinely interoperate across processes. At minimum, remove the paired-usage implication from the README until one of those is true.
Filed from the 2026-07-29 ecosystem audit register; independently re-verified against current HEAD before filing.
Location
src/bin/main.rs—cmd_sendandcmd_subscribe, each constructing its ownVirtualBus::new(); README.md quickstart section presentingrust-lin send/rust-lin subscribeas a usable pair.Problem
Each CLI subcommand instantiates a brand-new, independent
VirtualBus.subscribetherefore listens on a bus that no other process (or even any other invocation of the same binary) ever publishes to — it will simply block indefinitely waiting for frames that can never arrive.sendpublishes to a bus that's dropped the moment the process exits, so nothing it wrote is ever visible anywhere else. The README's quickstart walks through runningrust-lin send …andrust-lin subscribe …as if they communicate with each other, but as two separate CLI invocations they never share any transport, so that workflow can't actually work as documented.Suggested fix
Either make the README explicit that the in-process virtual bus can't bridge two separate CLI invocations (i.e. these are demo/smoke-test commands, not a real pub/sub pipe), or back the CLI with an actual shared transport (a local socket, named pipe, or similar) so
send/subscribecan genuinely interoperate across processes. At minimum, remove the paired-usage implication from the README until one of those is true.Filed from the 2026-07-29 ecosystem audit register; independently re-verified against current HEAD before filing.