You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
test(e2e): the wait-budget guard accepts a 1s margin and does not pin mongodb, rabbitmq or clickhouse #4418
hack/mariadb-first-boot-waits.bats lets two regressions of the wait budgets it was written to hold pass green.
The floor check accepts one second of margin. mbw_wait_clears_floor is [ "$1" -gt "$2" ], and a fixture pins 601 against 600 as ok. The reason docs/agents/e2e-testing.md gives for "strictly above" is that the wait's clock starts before the install's, by the Application reconcile, the chart artifact fetch and the helm-controller queue. One second covers none of that, so an edit from 660 back down to 601 passes every test and brings back the bare timeout the budgets exist to avoid. A named start margin (for example 60s) compared as floor + margin, with a fixture where 659 against 600 is refused, would close it.
The other three suites are not pinned at all. #3769 raised the mongodb, rabbitmq and clickhouse walkthrough database waits to 660s and grew each Chainsaw op by what its waits gained, for the same reason as mariadb: an op that runs out SIGKILLs the script and loses its error. The bats file holds only mariadb. Setting hack/e2e-chainsaw/rabbitmq/chainsaw-test.yaml back to timeout: 30m, or any of those waits back to 300, leaves the whole file green, while the same edit on mariadb turns it red. Either the floor and op checks become a per-suite table so the other three join the same contract, or the file header says that only mariadb is pinned and why.
Both came up in review of #3769 and were left out of it, because neither changes behaviour and a change there would have restarted the review and the E2E run.
Activity
test(e2e): hold the wait-budget guard to a start margin across four s…