Fix TestFormatDueDate year-boundary flake#514
Merged
Conversation
The same-year assertion used now.AddDate(0, 6, 0), which crosses into the next calendar year for any run after June — so from July onward the date carried a year and the 'should not contain year' assertion failed. Pick a date in the opposite half of the current year instead, keeping it same-year and clear of the today/tomorrow/yesterday window regardless of when in the year the suite runs.
There was a problem hiding this comment.
Pull request overview
Fixes a flaky TestFormatDueDate in the TUI workspace views by ensuring the “same year” test date never crosses into the next calendar year, keeping CI stable without changing production formatDueDate behavior.
Changes:
- Replaces the “6 months ahead” same-year test date with a deterministic month selection (Feb vs Nov) based on current month.
- Uses a fixed day-of-month (15th) to keep assertions stable and away from the today/tomorrow/yesterday window.
Tip
If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Address review: the test still read time.Now() while formatDueDate computed its own time.Now() internally, leaving a residual midnight/New-Year race where the two calls could observe different years. Extract formatDueDateAt(iso, now) as a testable seam (formatDueDate stays a thin wrapper passing time.Now()), and drive the test from a fixed reference now so none of the relative-label cases depend on the wall clock.
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
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.
Problem
TestFormatDueDatefails on any run after June, blocking CI onmainand every open PR:The "same year" case built its date with
now.AddDate(0, 6, 0)(6 months ahead). From July onward that lands in the next calendar year, soformatDueDatecorrectly includes the year — and theNotContains(year)assertion fails. It's a latent test bug that started firing as the calendar rolled forward; the productionformatDueDateis unaffected.Fix
Pick a same-year date in the opposite half of the current year (Feb if now is in H2, Nov if now is in H1). That guarantees it stays in the current calendar year and clear of the today/tomorrow/yesterday window no matter when in the year the suite runs.
Verification
TestFormatDueDatered (reproduces on cleanmain).TestFormatDueDateand the fullinternal/tui/workspace/viewspackage green.gofmt/go vetclean.Summary by cubic
Fixes a flaky
TestFormatDueDateand makes it fully deterministic by driving it from a fixednow. Keeps CI green without changingformatDueDatebehavior.formatDueDateAt(iso, now)and haveformatDueDatecall it withtime.Now()to remove midnight/New‑Year races.Written for commit 2fc8ef5. Summary will update on new commits.