2.4 KiB
Review: peer Pod handshake command
Reviewer Pods:
- Initial review:
peer-pod-handshake-reviewer-20260602 - Re-review:
peer-pod-handshake-rereviewer-20260602
Result
Approved after fixes. No remaining blockers.
Initial blocker findings
The first reviewer found two blockers:
SendToPeerPodwroteMethod::Notifydirectly to the target socket without draining connect-timeAlert/Snapshottraffic, so a real Pod socket could fail to process the notify while the sender reported success.- Reciprocal registration rollback could delete a pre-existing
source -> targetpeer relation when the reciprocaltarget -> sourcewrite failed.
Fix verification
Coder added commit 057c2ef fix: harden peer pod registration.
The re-review confirmed:
SendToPeerPodnow uses the existingconnect_and_sendone-shot client path, which drains connect-timeAlert/Snapshottraffic before writingMethod::Notifyand reports delivery failures.- A regression test covers a target socket that emits an alert/snapshot before reading the peer notify.
register_peernow snapshots the source Pod's existing peer list and restores that exact list if the target-side write fails.- A regression test covers an injected target-side failure where the source already had the peer relation and verifies it is preserved.
Validation evidence
Coder reported:
cargo test -p pod discovery --libcargo test -p tui command --libcargo test -p protocol -p pod-store -p pod -p tui --lib./tickets.sh doctorgit diff --checknix build .#yoi
Reviewer re-ran:
cargo test -p pod --lib peercargo test -p pod --lib connect_and_send
Parent/orchestrator reran after merge:
cargo test -p pod discovery --libcargo test -p tui command --libcargo test -p protocol -p pod-store -p pod -p tui --lib./tickets.sh doctorgit diff --checknix build .#yoi./result/bin/yoi pod --help
Residual risk
Peer registration updates two metadata files and is not crash-transactional because the current Pod metadata store has no multi-record transaction boundary. Normal write failures are handled by restoring the exact prior source peer list.
The implemented peer relationship is metadata-level reciprocal registration, not live target-process consent. This is documented and remains separate from spawned-child delegation, delegated scope, output cursors, parent ownership, and child completion notifications.