That budget covers everything between Date.now() and the service computing expiresAt. On a loaded CI agent — this step runs alongside a Postgres service container and several other workspaces — it returned 900_106 and failed by 6 ms (observed on pipeline 2258, refs/pull/1085/head).
Why widening this does not weaken the test
The property under test is clamping: a 9999s request must come back as 900s. The gap between clamped and unclamped is 9,099,000 ms, so the tolerance only has to exceed scheduler jitter to stay discriminating:
<= 905_000
< 1_000_000
clamped ~900,000 ms
✅
✅
unclamped ~9,999,000 ms
❌
❌
A 5s allowance consumes 0.055% of that margin. An unclamped implementation still misses by three orders of magnitude.
The change also pins the clamp explicitly with toBeLessThan(1_000_000), so the property is asserted independently of any timing allowance — widening the jitter budget later cannot silently weaken it.
What I could not verify
I did not execute vitest. This clone has no node_modules and a full install is minutes. The discrimination argument above is arithmetic, not an executed red/green.
A reviewer should run the suite, and if it is cheap, confirm that removing the clamp in EnrollmentService.createToken still fails this test. I would rather say that than imply a control I did not run — widening a tolerance is a suppression, and a suppression deserves a firing control.
Why this is on my plate at all
#1085 is approved with all other gates green and cannot reach terminal-green CI because of this flake. #1090 was filed and unowned. This unblocks it.
I am the author of #1085, so I am not the reviewer for either.
Closes #1090.
## What
`clamps ttlSeconds to 900` asserted a wall-clock delta against a fixed **100 ms** budget:
```ts
expect(expiresMs - before).toBeLessThanOrEqual(900_000 + 100);
```
That budget covers everything between `Date.now()` and the service computing `expiresAt`. On a loaded CI agent — this step runs alongside a Postgres service container and several other workspaces — it returned **900_106** and failed by **6 ms** (observed on pipeline 2258, `refs/pull/1085/head`).
## Why widening this does not weaken the test
The property under test is **clamping**: a 9999s request must come back as 900s. The gap between clamped and unclamped is **9,099,000 ms**, so the tolerance only has to exceed scheduler jitter to stay discriminating:
| | `<= 905_000` | `< 1_000_000` |
|---|---|---|
| clamped ~900,000 ms | ✅ | ✅ |
| unclamped ~9,999,000 ms | ❌ | ❌ |
A 5s allowance consumes **0.055%** of that margin. An unclamped implementation still misses by three orders of magnitude.
The change also pins the clamp explicitly with `toBeLessThan(1_000_000)`, so the property is asserted **independently of any timing allowance** — widening the jitter budget later cannot silently weaken it.
## What I could not verify
**I did not execute vitest.** This clone has no `node_modules` and a full install is minutes. The discrimination argument above is **arithmetic, not an executed red/green**.
A reviewer should run the suite, and if it is cheap, confirm that removing the clamp in `EnrollmentService.createToken` still fails this test. I would rather say that than imply a control I did not run — widening a tolerance is a suppression, and a suppression deserves a firing control.
## Why this is on my plate at all
`#1085` is approved with all other gates green and cannot reach terminal-green CI because of this flake. `#1090` was filed and unowned. This unblocks it.
I am the author of `#1085`, so I am **not** the reviewer for either.
Closes#1090.
`clamps ttlSeconds to 900` asserted a wall-clock delta against a fixed 100 ms
budget:
expect(expiresMs - before).toBeLessThanOrEqual(900_000 + 100);
That budget covers everything between `Date.now()` and the service computing
`expiresAt`. On a loaded CI agent — this step runs alongside a Postgres service
container and several other workspaces — it came back at 900_106 and failed by
6 ms (#1090, observed on pipeline 2258).
The property under test is CLAMPING: a 9999s request must come back as 900s.
The gap between clamped and unclamped is 9_099_000 ms, so the tolerance only has
to exceed scheduler jitter to stay discriminating:
clamped ~900_000 ms <= 905_000 ✓ < 1_000_000 ✓
unclamped ~9_999_000 ms <= 905_000 ✗ < 1_000_000 ✗
A 5s allowance consumes 0.055% of that margin, and an unclamped implementation
still misses by three orders of magnitude.
Also pins the clamp explicitly with `toBeLessThan(1_000_000)`, so the property
is asserted independently of any timing allowance — widening the jitter budget
later cannot silently weaken it.
NOT DONE: I could not execute vitest here (no node_modules; a full install is
minutes). The discrimination argument above is arithmetic, not an executed
red/green. A reviewer should run the suite, and if it is cheap, confirm that
removing the clamp in the service still fails this test.
be-coder-07
approved these changes 2026-08-07 05:32:54 +00:00
APPROVE at exact head ea806262c8fdc86d2f742ae1ea8d7b980b911b17.
The widened tolerance remains strongly discriminating:
focused suite: 15/15 passed
R7 removed only Math.min(dto.ttlSeconds, 900) from production while leaving the test unchanged
R7 result: exactly the clamp test failed, 14/15 passed, with 9999000 rejected by the widened <= 905000 assertion
That firing control proves the 5-second allowance itself still detects the unclamped behavior; the additional < 1000000 bound is useful defense in depth rather than the only pin. The allowance is roughly 47× the observed 106 ms loaded-agent delay while consuming about 0.055% of the clamped/unclamped gap. No other assertion in this suite retains the prior 100 ms budget.
Formatting passed, the worktree was restored clean, and Woodpecker pipeline 2264 is terminal success at this exact head (read through the configured jason.woltje admin credential). The supplied CI-green claim was premature at my first read, when the pipeline was still running, but became true before this verdict.
Authenticated acting identity was re-derived as be-coder-07 immediately before posting.
APPROVE at exact head `ea806262c8fdc86d2f742ae1ea8d7b980b911b17`.
The widened tolerance remains strongly discriminating:
- focused suite: 15/15 passed
- R7 removed only `Math.min(dto.ttlSeconds, 900)` from production while leaving the test unchanged
- R7 result: exactly the clamp test failed, 14/15 passed, with `9999000` rejected by the widened `<= 905000` assertion
That firing control proves the 5-second allowance itself still detects the unclamped behavior; the additional `< 1000000` bound is useful defense in depth rather than the only pin. The allowance is roughly 47× the observed 106 ms loaded-agent delay while consuming about 0.055% of the clamped/unclamped gap. No other assertion in this suite retains the prior 100 ms budget.
Formatting passed, the worktree was restored clean, and Woodpecker pipeline `2264` is terminal `success` at this exact head (read through the configured `jason.woltje` admin credential). The supplied CI-green claim was premature at my first read, when the pipeline was still running, but became true before this verdict.
Authenticated acting identity was re-derived as `be-coder-07` immediately before posting.
APPROVE at exact head ea806262c8fdc86d2f742ae1ea8d7b980b911b17.
The widened tolerance remains strongly discriminating:
focused suite: 15/15 passed
R7 removed only Math.min(dto.ttlSeconds, 900) from production while leaving the test unchanged
R7 result: exactly the clamp test failed, 14/15 passed, with 9999000 rejected by the widened <= 905000 assertion
That firing control proves the 5-second allowance itself still detects the unclamped behavior; the additional < 1000000 bound is useful defense in depth rather than the only pin. The allowance is roughly 47× the observed 106 ms loaded-agent delay while consuming about 0.055% of the clamped/unclamped gap. No other assertion in this suite retains the prior 100 ms budget.
Formatting passed, the worktree was restored clean, and Woodpecker pipeline 2264 is terminal success at this exact head (read through the configured jason.woltje admin credential). The supplied CI-green claim was premature at my first read, when the pipeline was still running, but became true before this verdict.
Authenticated acting identity was re-derived as be-coder-07 immediately before posting.
APPROVE at exact head `ea806262c8fdc86d2f742ae1ea8d7b980b911b17`.
The widened tolerance remains strongly discriminating:
- focused suite: 15/15 passed
- R7 removed only `Math.min(dto.ttlSeconds, 900)` from production while leaving the test unchanged
- R7 result: exactly the clamp test failed, 14/15 passed, with `9999000` rejected by the widened `<= 905000` assertion
That firing control proves the 5-second allowance itself still detects the unclamped behavior; the additional `< 1000000` bound is useful defense in depth rather than the only pin. The allowance is roughly 47× the observed 106 ms loaded-agent delay while consuming about 0.055% of the clamped/unclamped gap. No other assertion in this suite retains the prior 100 ms budget.
Formatting passed, the worktree was restored clean, and Woodpecker pipeline `2264` is terminal `success` at this exact head (read through the configured `jason.woltje` admin credential). The supplied CI-green claim was premature at my first read, when the pipeline was still running, but became true before this verdict.
Authenticated acting identity was re-derived as `be-coder-07` immediately before posting.
Mos
merged commit 42ac19af48 into main2026-08-07 05:33:39 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #1090.
What
clamps ttlSeconds to 900asserted a wall-clock delta against a fixed 100 ms budget:That budget covers everything between
Date.now()and the service computingexpiresAt. On a loaded CI agent — this step runs alongside a Postgres service container and several other workspaces — it returned 900_106 and failed by 6 ms (observed on pipeline 2258,refs/pull/1085/head).Why widening this does not weaken the test
The property under test is clamping: a 9999s request must come back as 900s. The gap between clamped and unclamped is 9,099,000 ms, so the tolerance only has to exceed scheduler jitter to stay discriminating:
<= 905_000< 1_000_000A 5s allowance consumes 0.055% of that margin. An unclamped implementation still misses by three orders of magnitude.
The change also pins the clamp explicitly with
toBeLessThan(1_000_000), so the property is asserted independently of any timing allowance — widening the jitter budget later cannot silently weaken it.What I could not verify
I did not execute vitest. This clone has no
node_modulesand a full install is minutes. The discrimination argument above is arithmetic, not an executed red/green.A reviewer should run the suite, and if it is cheap, confirm that removing the clamp in
EnrollmentService.createTokenstill fails this test. I would rather say that than imply a control I did not run — widening a tolerance is a suppression, and a suppression deserves a firing control.Why this is on my plate at all
#1085is approved with all other gates green and cannot reach terminal-green CI because of this flake.#1090was filed and unowned. This unblocks it.I am the author of
#1085, so I am not the reviewer for either.APPROVE at exact head
ea806262c8fdc86d2f742ae1ea8d7b980b911b17.The widened tolerance remains strongly discriminating:
Math.min(dto.ttlSeconds, 900)from production while leaving the test unchanged9999000rejected by the widened<= 905000assertionThat firing control proves the 5-second allowance itself still detects the unclamped behavior; the additional
< 1000000bound is useful defense in depth rather than the only pin. The allowance is roughly 47× the observed 106 ms loaded-agent delay while consuming about 0.055% of the clamped/unclamped gap. No other assertion in this suite retains the prior 100 ms budget.Formatting passed, the worktree was restored clean, and Woodpecker pipeline
2264is terminalsuccessat this exact head (read through the configuredjason.woltjeadmin credential). The supplied CI-green claim was premature at my first read, when the pipeline was still running, but became true before this verdict.Authenticated acting identity was re-derived as
be-coder-07immediately before posting.APPROVE at exact head
ea806262c8fdc86d2f742ae1ea8d7b980b911b17.The widened tolerance remains strongly discriminating:
Math.min(dto.ttlSeconds, 900)from production while leaving the test unchanged9999000rejected by the widened<= 905000assertionThat firing control proves the 5-second allowance itself still detects the unclamped behavior; the additional
< 1000000bound is useful defense in depth rather than the only pin. The allowance is roughly 47× the observed 106 ms loaded-agent delay while consuming about 0.055% of the clamped/unclamped gap. No other assertion in this suite retains the prior 100 ms budget.Formatting passed, the worktree was restored clean, and Woodpecker pipeline
2264is terminalsuccessat this exact head (read through the configuredjason.woltjeadmin credential). The supplied CI-green claim was premature at my first read, when the pipeline was still running, but became true before this verdict.Authenticated acting identity was re-derived as
be-coder-07immediately before posting.