v4.2.2 — an answer may not say VFB holds nothing until something has looked - #19
Merged
Conversation
…looked Version bump and release notes only. Landing this before the merge, not after: v4.2.1 was tagged against a main that still said 4.2.0 in package.json, which is exactly the fiction lib/appVersion.mjs exists to prevent.
Only conflict was test-results/task-battery/latest.json, which CI regenerates on every run; taking main's copy.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Version bump and release notes only — no code. #17 and #18 are the substance.
Landing this before asking for the merge, not after: v4.2.1 was tagged
against a main that still said
4.2.0inpackage.json, which is precisely thefiction
lib/appVersion.mjsexists to prevent.package.json/package-lock.json: 4.2.1 → 4.2.2RELEASE_NOTES.md: the v4.2.2 entry1188 unit tests, 0 failures. Task battery 64/64 on the merged main.
One thing this PR could not carry
.github/workflows/task-battery.ymlwantsTASK_BATTERY_TIMEOUT_MS240000→360000. Both the git push and the Contents API refuse it — GitHubenforces the
workflowscope on every route and this token does not have it.The case for it:
T3.8has run at 189,745 / 196,322 / 201,012 ms against a240,000 ms ceiling, so it has been a coin flip for several releases rather than
a signal. The same commit passed it in one battery run and timed out in another,
and on the run where it timed out it had not escalated at all — the slowness is
the task, not the 4.2.2 guard. Every other task in the battery completes inside
206 s, so 360 s gives T3.8 the margin it has always needed without weakening the
ceiling for anything else. A timeout that fires on a healthy task teaches people
to re-run red builds, which is worse than no ceiling at all.
Until it lands, the battery can be verified at the intended ceiling with
gh workflow run task-battery.yml -f timeout_ms=360000, which is how thisrelease was checked.