test: pick the newest handbook commit by author date, not traversal order - #5751
Merged
Merged
Conversation
…l order The handbook recent-changes test asked git for `log -1` and asserted that weeks[0] was that commit's week. Those are two different commits whenever a change is authored before, but lands after, another one. git ranks traversal by COMMIT date. getHandbookChanges buckets weeks by AUTHOR date and sorts on it, which the module already documents and does deliberately. So the two agree only while author dates happen to be monotonic with merge order: any rebase breaks it, and so does an ordinary PR that sat open while a later-authored one merged ahead of it. Caught while rebasing another branch: the tip was authored 2026-09-03 while the newest handbook change was authored 2026-09-07, putting the test's "latest" and the module's weeks[0] in different weeks. Nothing was wrong with the module. The test now parses the full log and takes the maximum author date, which is what weeks[0] is built from. Ties on a date are harmless, since same-date commits share a week. Worth knowing: this never failed CI. git is not on the PATH in that job, so getHandbookChanges takes its documented git-unavailable path and the assertions never run. The failure is only reachable locally, which is where it was found.
✅ Deploy Preview for flowforge-website ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Contributor
Author
|
came across this while developing #5750 |
Yndira-E
approved these changes
Sep 7, 2026
This branch was successfully deployed
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.
Description
Fixes a latent flaky assertion in
handbookChanges.test.mjs. Test-only; the module is unchanged and was never at fault.The test asked git for
log -1and assertedweeks[0]was that commit's week. But:getHandbookChangesbuckets weeks by author date, and says so in a commentThose agree only while author dates happen to be monotonic with merge order. Any rebase breaks it, so does a PR that sat open while a later-authored one merged ahead of it.
Caught while rebasing an unrelated branch: tip authored 09-03, newest handbook change authored 09-07, two different weeks.
The test now takes the maximum author date, which is what
weeks[0]is built from. Verified onmainand on the history that exposed it.Side note
This could not have failed CI. git isn't on the PATH in
test_website, sogetHandbookChangesreturns[]and every integration assertion in this file silently doesn't run. Left alone here, since fixing it is a workflow change.Related Issue(s)
None.
Checklist