fix(availability): give each window room for a check that times out #203

Merged

binjovi-bot merged 1 commit from fix/availability-window-holds-a-retry into trunk

2026-09-10 11:10:18 +00:00

sean commented

2026-09-10 11:09:18 +00:00

Owner

Both seanfarm profiles ran a timeout the window could not absorb:

profile	duration	timeout	needs
`binjovi-control-plane`	2s	2s	4s
`platform-core`	3s	2s	4s

A sample runs its checks together, so one slow sample costs a whole timeout. Either window ends on that first sample and the probe reports one sample: a failed Deploy that measured nothing about the release.

Binjovi failed exactly this way with a 10s timeout inside a 5s window (binjovi-staging, v0.1.579, 2026-09-10) — the rollout had already verified 2/2 replicas ready, and a retry passed first time. Both windows here are now 4s, twice their timeout, the ratio Binjovi's own gate now uses.

scripts/check refuses a window shorter than two timeouts, wherever the policy sits in the bundle. Three negative controls keep it honest: a longer timeout, a shorter duration, and a bundle with no policy at all. Checked with make check.

This lands before Binjovi enforces the same rule in AvailabilityPolicy.parse — a bundle that fails validation does not replace the active bundle, so the order matters.

https://claude.ai/code/session_01HHv7J8uwGo3cqiy6XxSyiG

Both `seanfarm` profiles ran a timeout the window could not absorb: | profile | duration | timeout | needs | |---|---|---|---| | `binjovi-control-plane` | 2s | 2s | 4s | | `platform-core` | 3s | 2s | 4s | A sample runs its checks together, so one slow sample costs a whole timeout. Either window ends on that first sample and the probe reports one sample: a failed Deploy that measured nothing about the release. Binjovi failed exactly this way with a 10s timeout inside a 5s window (`binjovi-staging`, v0.1.579, 2026-09-10) — the rollout had already verified 2/2 replicas ready, and a retry passed first time. Both windows here are now **4s**, twice their timeout, the ratio Binjovi's own gate now uses. `scripts/check` refuses a window shorter than two timeouts, wherever the policy sits in the bundle. Three negative controls keep it honest: a longer timeout, a shorter duration, and a bundle with no policy at all. Checked with `make check`. This lands before Binjovi enforces the same rule in `AvailabilityPolicy.parse` — a bundle that fails validation does not replace the active bundle, so the order matters. https://claude.ai/code/session_01HHv7J8uwGo3cqiy6XxSyiG

sean added 1 commit

2026-09-10 11:09:18 +00:00

fix(availability): give each window room for a check that times out

binjovi/ci Binjovi completed the frozen plan

Details

78eb72949f

Both seanfarm profiles ran a timeout that the window could not absorb:
`binjovi-control-plane` had a 2s timeout in a 2s window, and
`platform-core` a 2s timeout in a 3s window. A sample runs its checks
together, so one slow sample costs a whole timeout. Either window ends
on that first sample, and the probe reports one sample: a failed Deploy
that measured nothing about the release.

Binjovi failed exactly this way with a 10s timeout in a 5s window
(binjovi-staging, v0.1.579, 2026-09-10). Both windows are now 4s, twice
their timeout, which is the ratio Binjovi's own gate now uses.

`scripts/check` refuses a window shorter than two timeouts, wherever the
policy sits in the bundle. Three negative controls hold it honest: a
longer timeout, a shorter duration, and a bundle with no policy at all.

Claude-Session: https://claude.ai/code/session_01HHv7J8uwGo3cqiy6XxSyiG

sean changed target branch from main to trunk

2026-09-10 11:09:51 +00:00

binjovi-bot merged commit 78eb72949f into trunk

2026-09-10 11:10:18 +00:00

No reviewers

No labels

No milestone

No project

No assignees

1 participant

Notifications

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

sean/binjovi-plans!203

No description provided.

Rows
Columns