fix(test): give cert-revocation more cert life than discovery needs #158

Merged

vxfemboy merged 2 commits from fix/cert-revocation-discovery-budget into main 2026-08-04 00:36:19 +00:00

Conversation 0 Commits 2 Files changed 2 +43 -5

vxfemboy commented 2026-08-03 21:00:28 +00:00

Owner

Copy link

Fixes half of #157 — the hardening.41 cert-revocation flake.

CERT_A_SECS was 60. Step 8's retry loop stops 5s before expiry so the "still valid" invariant stays honest, leaving 55s of usable convergence window. But run-netns-discovery.sh:287 documents gossip warm-up as needing "up to a 60s budget".

The test allocated less time than its own sibling says the thing it waits for can take. That is why it flaked rather than failed outright: a green run was simply one that converged early, and runner load only decided which side of the line a run landed on. Commit 3cf588f failed this test on run 305 and passed it on run 306.

150s is ~2.5x the documented worst case.

The assertion is unchanged. The cert still expires mid-test — that is the entire point of the revocation check, and steps 9-11 (drop detection, no re-admission) are untouched. Every downstream deadline derives from CERT_A_SECS, so nothing else needed editing.

Cost: step 9's wait-for-expiry grows by the same 90s, on a job that runs ~31 minutes and has no timeout-minutes set.

Not addressed here: the arq_recovers_bulk_loss flake, also in #157. That one needs a decision (is the 98% floor mis-calibrated, or is recovery genuinely inconsistent?) rather than a number change, so it does not belong in this PR.

Fixes half of #157 — the `hardening.41` cert-revocation flake. `CERT_A_SECS` was 60. Step 8's retry loop stops 5s before expiry so the "still valid" invariant stays honest, leaving **55s** of usable convergence window. But `run-netns-discovery.sh:287` documents gossip warm-up as needing **"up to a 60s budget"**. The test allocated less time than its own sibling says the thing it waits for can take. That is why it flaked rather than failed outright: a green run was simply one that converged early, and runner load only decided which side of the line a run landed on. Commit `3cf588f` failed this test on run 305 and passed it on run 306. 150s is ~2.5x the documented worst case. **The assertion is unchanged.** The cert still expires mid-test — that is the entire point of the revocation check, and steps 9-11 (drop detection, no re-admission) are untouched. Every downstream deadline derives from `CERT_A_SECS`, so nothing else needed editing. **Cost:** step 9's wait-for-expiry grows by the same 90s, on a job that runs ~31 minutes and has no `timeout-minutes` set. Not addressed here: the `arq_recovers_bulk_loss` flake, also in #157. That one needs a decision (is the 98% floor mis-calibrated, or is recovery genuinely inconsistent?) rather than a number change, so it does not belong in this PR.

vxfemboy added 1 commit 2026-08-03 21:00:29 +00:00

fix(test): give cert-revocation more cert life than discovery needs ... 49bdcc6f05

CERT_A_SECS was 60. The retry loop in step 8 stops 5s before expiry to keep
the "still valid" invariant honest, so the usable convergence window was 55s
-- while run-netns-discovery.sh:287 documents gossip warm-up as needing "up
to a 60s budget". The test allocated less time than its own sibling says the
thing it waits for can take.

That is why it flaked rather than failed: a green run was one that happened
to converge early. Runner load only decided which side of the line a given
run landed on. Same commit 3cf588f failed this test on run 305 and passed it
on run 306, failing arq_recovers_bulk_loss instead.

150s is ~2.5x the documented worst case. The assertion is unchanged -- the
cert still expires mid-test, which is the whole point of the revocation
check. Every downstream deadline derives from CERT_A_SECS, so the only cost
is step 9's wait-for-expiry growing by the same 90s, on a job that runs ~31
minutes and has no timeout-minutes set.

Refs #157.

vxfemboy referenced this pull request from a commit 2026-08-03 22:19:28 +00:00

docs(changelog): record the CI tooling fix (#156) and the cert-revocation budget (#158)

vxfemboy added 1 commit 2026-08-03 22:19:28 +00:00

docs(changelog): record the CI tooling fix (#156) and the cert-revocation budget (#158) ... c6c70e16ae

Neither was in the changelog. #156 is the one worth reading later: three
privileged jobs drove ip/tcpdump/iperf3 without declaring them, and one of
them only ever worked because wireguard-tools listed iproute2 as a
Recommends -- so it broke the day apt stopped resolving it, with nothing in
the repo having changed.

vxfemboy referenced this pull request 2026-08-03 22:23:49 +00:00

netns-tunnel-test: two intermittent failures (cert-revocation budget vs documented discovery time; ARQ floor inside noise band) #157

vxfemboy referenced this pull request from a commit 2026-08-03 23:53:20 +00:00

fix(test): make flowshape check robust via dense-cluster span, not gap cutoff

vxfemboy referenced this pull request 2026-08-03 23:53:58 +00:00

fix(test): robust flowshape check (dense-cluster span) #159

vxfemboy merged commit 6a1a1a5e8e into main 2026-08-04 00:36:19 +00:00

vxfemboy deleted branch fix/cert-revocation-discovery-budget 2026-08-04 00:36:20 +00:00

vxfemboy referenced this pull request from a commit 2026-08-04 00:36:22 +00:00

Merge pull request 'fix(test): give cert-revocation more cert life than discovery needs' (#158) from fix/cert-revocation-discovery-budget into main

vxfemboy referenced this pull request 2026-08-04 05:52:40 +00:00

netns-tunnel-test: two intermittent failures (cert-revocation budget vs documented discovery time; ARQ floor inside noise band) #157

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

bug

Something isn't working

  

documentation

Improvements or additions to documentation

  

duplicate

This issue or pull request already exists

  

enhancement

New feature or request

  

good first issue

Good for newcomers

  

help wanted

Extra attention is needed

  

invalid

This doesn't seem right

  

question

Further information is requested

  

wontfix

This will not be worked on

No labels

bug

documentation

duplicate

enhancement

good first issue

help wanted

invalid

question

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

femboy/yip!158

No description provided.