mirror of
https://github.com/hanzoai/status.git
synced 2026-10-30 18:21:48 +00:00
zeekay
8115a42997
The GRPC endpoint type was behind `//go:build grpc` with a stub that told the operator to "rebuild with -tags grpc to enable, or use the ZAP-native endpoint type". There was no ZAP endpoint type — only the unrelated Zapier alerting provider — so the check was off in every build we ship and the alternative it named had never been written. `zap://` is that type. It dials whatever ZAP dials (a unix socket path or a host:port) and reports whether a peer answers. A refusal is an answer: the probe asks for an op nothing implements, and zip reports a transport failure as its own 502 while rebuilding a callee's refusal with the status the callee chose — so an *HTTPError of any other status came back over a completed round trip. A 502 is the one status both cases produce, so it is never read as evidence and an unreachable peer is never reported up. There is no ZAP health op to call instead, and that is zip's decision rather than an omission: /healthz lives on the ops listener and is HTTP on purpose, because a ZAP socket reads bytes as frames and "GET " arrives as frame size 1195725856. An endpoint that wants /healthz is an http:// endpoint already. What only ZAP can answer is whether the peer is there. google.golang.org/grpc is no longer a direct dependency. What remains is transitive through google.golang.org/api/idtoken, which client/config.go uses to mint GCP OIDC tokens for monitored endpoints. Both directions are pinned against a real peer on a real socket, and both mutations were watched to fail.