Every kubectl invocation in hack/e2e-capture-dataplane.sh currently carries a wall-clock bound, but nothing enforces that, so the next one added can go unbounded without any test noticing.
The property holds today. Classifying every call in the file by what wraps it gives 26 under a literal timeout <n>, 6 under $DP_BOUND, 2 under $DP_LIST_BOUND, and none unwrapped. Two categories sit outside that count and are worth naming so the number is not read as larger than it is: three non-kubectl probes (nc, curl, wget) run inside sh -c under a bounded kubectl exec and additionally carry their own -w 5 / --max-time 6 / -T 6; and when the timeout binary is absent from the image, $DP_BOUND expands empty and those reads run unbounded, which is a deliberate choice rather than an oversight -- the alternative fails each call with 127 and produces an artifact claiming kubectl died when kubectl never ran.
There is a guard for this property elsewhere in the tree (hack/cozyreport.bats, hack/tenant-pre-delete-hook.bats), and it does not take this file as its subject. So the invariant is currently satisfied and unguarded: a new read added six months from now passes review as easily as it passes CI.
Two requirements on the guard itself, both learned from writing the audit by hand:
It has to match on command position, not on the presence of the word timeout somewhere in the line. A naive grep over this file produces four false hits: two are printf statements inside dp_read_outcome where the word appears in a message, and two are indented comments.
It has to list the offending call sites by name rather than assert a count. A related guard that already does this caught five unbounded reads on a branch recently, and naming them turned the diagnosis into a single command instead of a search. A count tells the next author that something is wrong; a list tells them where.
The guard should also be pinned by mutation before it is trusted: add a bare kubectl get pods to the script and confirm the guard names that line. Otherwise the outcome is a check that is green because it looks for nothing, which is the failure mode this class of test exists to prevent.
Every
kubectlinvocation inhack/e2e-capture-dataplane.shcurrently carries a wall-clock bound, but nothing enforces that, so the next one added can go unbounded without any test noticing.The property holds today. Classifying every call in the file by what wraps it gives 26 under a literal
timeout <n>, 6 under$DP_BOUND, 2 under$DP_LIST_BOUND, and none unwrapped. Two categories sit outside that count and are worth naming so the number is not read as larger than it is: three non-kubectl probes (nc,curl,wget) run insidesh -cunder a boundedkubectl execand additionally carry their own-w 5/--max-time 6/-T 6; and when thetimeoutbinary is absent from the image,$DP_BOUNDexpands empty and those reads run unbounded, which is a deliberate choice rather than an oversight -- the alternative fails each call with 127 and produces an artifact claiming kubectl died when kubectl never ran.There is a guard for this property elsewhere in the tree (
hack/cozyreport.bats,hack/tenant-pre-delete-hook.bats), and it does not take this file as its subject. So the invariant is currently satisfied and unguarded: a new read added six months from now passes review as easily as it passes CI.Two requirements on the guard itself, both learned from writing the audit by hand:
It has to match on command position, not on the presence of the word
timeoutsomewhere in the line. A naive grep over this file produces four false hits: two areprintfstatements insidedp_read_outcomewhere the word appears in a message, and two are indented comments.It has to list the offending call sites by name rather than assert a count. A related guard that already does this caught five unbounded reads on a branch recently, and naming them turned the diagnosis into a single command instead of a search. A count tells the next author that something is wrong; a list tells them where.
The guard should also be pinned by mutation before it is trusted: add a bare
kubectl get podsto the script and confirm the guard names that line. Otherwise the outcome is a check that is green because it looks for nothing, which is the failure mode this class of test exists to prevent.