Repository navigation
e2e(gateway, redis-tls): remaining unbounded cleanup and swallowed errors #4644
Description
After #4643, the gateway and redis-tls e2e suites still have a few waits that can run past their op and errors that get replaced by a fixed guess. Each has the same shape as #4114 or #4246, in a step that PR didn't touch.
- Gateway, the VAP-probe cleanup (around line 239 of
hack/e2e-chainsaw/gateway/chainsaw-test.yaml):kubectl delete tenants.apps.cozystack.io vaphostprobehas no--timeoutand no--wait=false, so a stuck finalizer holds the trap until the op kills it. - Gateway, the listener-set polls: a poll that hits its
timeout N sh -ecexits 124 underset -ewithout naming which wait expired. - redis-tls, the TLS PONG fallback:
|| pong='(no reply: redis-cli failed or hit the 15s cap)'throws away the real exit status and output. - redis-tls, the sentinel lookup:
-o jsonpath='{.items[0].metadata.name}'fails hard on an empty list, and the step exits with no message of its own.
Fix shape: a --timeout on the probe delete with the op sized to include it, a named failure line on each poll, capture rc and stderr in the PONG check the way the plaintext check does, and read {.items[*]...} with a named failure when the list is empty.
Activity
lexfrei commentedon Oct 2, 2026
Two more of the same shape, found while reworking #4643.
The listener-set step in the gateway suite runs three
kubectl applyand onekubectl get ns ... -o jsonpathlabel read with no time limit. Its polls and cleanup deletes all run undertimeout, and the budget guard inhack/chainsaw-op-budgets.batsonly keeps a flat 60s of headroom for these four calls. That 60s is an assumption, not a bound. A stalled request runs until the op ceiling, Chainsaw kills the shell, and the cleanup trap never runs. The fix is to run them undertimeout -klike the deletes and let the guard sum them.The PONG fallback with "or hit the 15s cap" is in two places in
hack/e2e-chainsaw/redis/chainsaw-test.yaml, not one: the TLS check and theredis-tls-flip-rejectedcheck further down. Both need the rc and stderr capture.lexfrei commentedon Oct 2, 2026
One more misreported failure in redis-tls, in the CA-projection step after #4643. The check that
redis-secure.ca-tlsstill carriestls.keypipes the key list intogrep -x 'tls.key', and any failure of that pipeline prints "redis-secure.ca-tls no longer carries tls.key: this check has stopped proving anything". A failed read of the Secret (an API error, or the step budget already spent) ends up with that message too. kubectl's own error is still printed above it, but the last line points at the Secret's content instead of the read. The step runs under pipefail now, so the read's exit status is there to tell the two apart.lexfrei commentedon Oct 5, 2026
One more from the review of #4643, a comment this time. The cleanup comment in the gateway listener-set step (line 1000 at 2ddd55c) says 124 is the bound. The deletes run under
timeout -k 5, so a kubectl that ignores SIGTERM gets the SIGKILL and exits 137. The comment should name both codes (comment).