The `canaries` field in `Ping` (ping.proto, field 2) documents its keys as "the peer Node's IPv4 address in dotted form ("203.0.113.7")". The `Peer` message in pong.proto (field 1) delivers the same address as `bytes ip = 1;` — four raw bytes in network byte order.
When a client observes probe failures against peers received in `Pong.servers`, it must convert each `Peer.ip` from raw bytes to a dotted-decimal string before inserting it as a `canaries` key. A client that uses the raw bytes directly — the natural choice given the `bytes` type — inserts a four-character binary key such as `"\xcb\x00\x71\x07"` rather than `"203.0.113.7"`. The Node cannot match that key against any peer in its fleet, so every failure report from that client is silently dropped.
Neither the `Peer.ip` comment nor the `Ping.canaries` comment mentions the conversion. The related inconsistency in `Property.ip` is tracked in #1, but the canaries case is more severe: the failure is operationally silent. A Node with rising probe-failure rates will not be retired because no client's failure reports reach the Hub under the correct key, allowing a degraded Node to stay in rotation longer than it should.
Fix: add one sentence to the `Peer.ip` comment stating that clients must format the bytes as dotted-decimal when using the address as a `Ping.canaries` key, or change `map<string, uint32> canaries` to `map<bytes, uint32>` in ping.proto to match the `Peer.ip` encoding and eliminate the conversion entirely.
The `canaries` field in `Ping` (ping.proto, field 2) documents its keys as "the peer Node's IPv4 address in dotted form ("203.0.113.7")". The `Peer` message in pong.proto (field 1) delivers the same address as `bytes ip = 1;` — four raw bytes in network byte order.
When a client observes probe failures against peers received in `Pong.servers`, it must convert each `Peer.ip` from raw bytes to a dotted-decimal string before inserting it as a `canaries` key. A client that uses the raw bytes directly — the natural choice given the `bytes` type — inserts a four-character binary key such as `"\xcb\x00\x71\x07"` rather than `"203.0.113.7"`. The Node cannot match that key against any peer in its fleet, so every failure report from that client is silently dropped.
Neither the `Peer.ip` comment nor the `Ping.canaries` comment mentions the conversion. The related inconsistency in `Property.ip` is tracked in #1, but the canaries case is more severe: the failure is operationally silent. A Node with rising probe-failure rates will not be retired because no client's failure reports reach the Hub under the correct key, allowing a degraded Node to stay in rotation longer than it should.
Fix: add one sentence to the `Peer.ip` comment stating that clients must format the bytes as dotted-decimal when using the address as a `Ping.canaries` key, or change `map<string, uint32> canaries` to `map<bytes, uint32>` in ping.proto to match the `Peer.ip` encoding and eliminate the conversion entirely.