test: the identity probes wait for an answer, not for a Running pod

[kfeofantov]

The follow-up flagged in #129: make identity-e2e failed on main, and a control run against an image built from b495a1a failed identically, so it was never the toolchain.

The test said what it needed and then did not ask for it

Both tests open with the same comment:

The controller must be answering before a refusal means anything: a connection refused would satisfy "not 200" without proving a thing.

and then called waitDeploymentPod, which returns on Running. The probe reaches the controller through its Service, and the Service carries no endpoint until the pod is Ready — readiness means the informer caches have synced (ADR 0069). Every request inside that window is refused at connect, and wget reports no HTTP status, so three subtests failed on exactly the ambiguity the comment warned about.

The fix is the precondition itself

waitReceiverAnswering sends an unauthenticated probe until the receiver answers with any HTTP status — a refusal is the expected answer, and what is being waited for is the conversation, not the verdict. probeReceiver keeps its fatal verdict and delegates the attempt to tryProbeReceiver, which reports a connect failure as a zero status rather than as a fatal.

This also closes the kube-proxy programming lag that waiting on the pod's Ready condition alone would leave open: what is asserted is that this caller, from this pod, got an answer.

Evidence

make identity-e2e   # PASS, both tests
  identity_test.go:76: the receiver answers: .../v1/node-scope returned 401
                       to an unauthenticated probe

The subtests now run in ~0.05s each, down from ~1.1s — that second was the connect failing.

Same family as #121: an e2e assertion that could not distinguish the thing it tested from the environment it ran in.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KeZECJXTDHL6Nts95eKMJA