Peering panel: per-peer "Test" button — run the control-plane handshake without sending data #142
Labels
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Cordy/Cairn#142
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
From the #106 dogfood: registering a peer with a wrong URL/scheme surfaces only at the first real send, in the worst place (a failed transfer in the user's Transfers view). Two live examples within one hour: an
https://URL dialing a plain-HTTP peer, and the portless-URL→443 gRPC default (#140). Both would have been caught at registration time by a connectivity test.Design: a Test button on each row of "Instances you can send to" (and offered right after registering).
POST /api/v1/admin/peering/peers/{name}/test(admin-gated like the other peering admin routes). RunsHello+Authenticateagainst the peer using the stored URL and key — the real client code path incl.grpcTarget— with a short timeout (~5s). No transfer is prepared; nothing is written on either side.{ ok: true }or{ ok: false, error: "<the actual gRPC/transport error>" }— the raw error is the value; it is exactly what the admin needs to distinguish "wrong URL", "wrong key", "peering disabled on the far side" (503), and "TLS/h2 mismatch".Honest scope note: this validates URL + key + transport. It deliberately does NOT validate the sender/receiver allowlists (a local-config concern the panel already shows per row since #129) and does not prove the data plane (that needs a transfer). Name the button "Test connection" so it doesn't overpromise.
Shipped in v0.4.12 (PR #149), live on the dogfood. As specced: "Test connection" button per peer row → admin
POST /api/v1/admin/peering/peers/{name}/test→ newClient.Pingruns Hello + Authenticate through the REAL client path (grpcTargetdial derivation included), 5s timeout, no transfer prepared, nothing written on either side. Response is{ok:true}or{ok:false, error:"<raw gRPC/transport error>"}— the raw error is deliberately the payload, since it distinguishes wrong URL / wrong key / peering-disabled-503 / h2 mismatch at a glance. Result renders inline in the row (✓ green / ✗ red + message), not in the dialog's global message line. Both test invocations audited. Would have caught #140 and #143 at registration time — which is why it exists.