fix(#277): MCP accept pins a routable peer + accept flags loopback-only reply path#331
Merged
Merged
Conversation
…ly reply path Two honesty/routing gaps in the bilateral-accept path, both surfaced by #277. 1. **MCP wire_accept wrote an unroutable pin.** The MCP accept path still wrote the peer pin in the flat `peers[h]={relay_url,slot_id,slot_token}` shape that RFC-006 Part B (#268) no longer reads — so a peer accepted over MCP landed with an empty `endpoints[]` and `wire send` couldn't route to them at all. Now pins via `endpoints::pin_peer_endpoints` (the `endpoints[]` single source), matching the CLI accept path. (Another Part B writer-straggler, like the reader ones #323 fixed.) 2. **Accept reported success on an unreachable reply path.** Both `wire accept` (CLI) and the MCP accept returned `bilateral_accepted` even when the peer advertised only loopback/same-host endpoints — the #277 report: trust pinned, but the reply path can't reach a remote peer, and nothing said so. New `endpoints::endpoints_are_local_only` (infers from the URL, so a loopback address mislabeled `scope:"federation"` — the exact #277 case — is still caught) drives a `reply_path_reachable:false` field on both paths + a remediation warning on the CLI. Trust is still pinned (it's real); the link's reachability is just no longer silently overstated. Unit-tested the helper (empty→false, mislabeled-loopback caught, federation ok, mixed ok, UDS local-only). 598 lib tests green; clippy clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Deploying wireup-landing with
|
| Latest commit: |
a066cee
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://f3efcd79.wireup-landing.pages.dev |
| Branch Preview URL: | https://fix-277-accept-reachability.wireup-landing.pages.dev |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Closes the operator-experience half of #277 (the code-routing half landed in #323). Two gaps in the bilateral-accept path:
1. MCP
wire_acceptwrote an unroutable pinThe MCP accept path still wrote the peer pin in the flat
peers[h]={relay_url,slot_id,slot_token}shape that RFC-006 Part B (#268) no longer reads — so a peer accepted over MCP got an emptyendpoints[]andwire sendcouldn't route to them at all. Now pins viaendpoints::pin_peer_endpoints(theendpoints[]single source), matching the CLI path. (Another Part-B writer straggler, like the reader ones #323 fixed.)2. Accept reported success on an unreachable reply path
Both
wire accept(CLI) and MCP accept returnedbilateral_acceptedeven when the peer advertised only loopback/same-host endpoints — exactly the #277 report: trust pinned, but the reply path can't reach a remote peer, and nothing said so.New
endpoints::endpoints_are_local_onlydrives areply_path_reachable: falsefield on both paths + a remediation warning on the CLI. It infers reachability from the URL (not the advertisedscope), so a loopback address mislabeledscope:"federation"— the exact #277 churn case — is still caught. Trust is still pinned (it's real); the link's reachability is just no longer silently overstated.Tests
endpoints_are_local_only_catches_loopback_pin_incl_mislabeled_scope(empty→false, mislabeled-loopback caught, federation ok, mixed ok, UDS local-only).-D warningsclean.Stacks cleanly with #330 (SSO docs, no file overlap).
🤖 Generated with Claude Code