Repository navigation
Fix two tests that fail for three hours every night - #53
Merged
Merged
Conversation
Both assert that an email names the right date, and both compare against the
UTC date:
Assert.Contains(start.ToString("dd/MM/yyyy"), answer.Subject);
Email subjects are written in Israel time. Between 21:00 and 24:00 UTC that
is already the next day there, so the two disagree and the tests fail:
Assert.Contains() Failure: Sub-string not found
String: "בקשת השיעור של תלמידה מבקשת לא אושרה — 25"···
Not found: "24/09/2026"
Nothing is wrong with the code under test — the email is correct and the
assertion is not. They now compare against EmailTime.Date, which is what the
subject is built from, so they say what they mean and pass at any hour.
Found while running the suite at 22:25 UTC.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Adding a parent or a student creates their account and emails them an invitation to set a password. That email goes out exactly once, and a send that fails is only written to the log — AccountProvisioning catches the exception so the teacher's save does not fail with it. So a parent who never received it — a failed send, a spam folder, a link that expired — had no way in, and the teacher had no way to help her and no way to even know. There was no resend anywhere in the app. Setting a password from the invitation is what verifies the address, so EmailConfirmed already says who has come in. That now reaches the lists as AccountActivated, the students screen marks the ones still waiting, and a button next to them sends the invitation again. Refused where it would be wrong: someone who already set a password (409), a student with no sign-in of her own (409), and another teacher's parent (404, through the tenant filter).
Let the teacher see who never got in, and send the invitation again
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
1 participant
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.
I ran the suite at 22:25 UTC and two tests failed:
Nothing is wrong with the code under test. Both tests check that an email names the right date, and both compare against the UTC date:
Email subjects are written in Israel time. Between 21:00 and 24:00 UTC — midnight to 03:00 in Israel — that is already the next day there, so the assertion and the email disagree. The email is right; the assertion is not.
So the suite is red for three hours a night, every night, on a correct tree. Anyone whose CI happens to run in that window — or who works late — chases a bug that is not there.
They now compare against
EmailTime.Date, the helper the subject itself is built from, so they assert what they mean: the email names this lesson's date, in the timezone the email is written in. The conversion itself is already covered separately byEmailTimeZoneTests.The third place that formats a date this way,
EmailTimeZoneTests:81, already converts to Israel time first and was fine.Testing
dotnet test— 250 passing, run at 22:25 UTC, inside the window where the two used to fail.