Skip to content

Address ready_to_verify_presenter_spec flaky tests.#9652

Merged
JackRyan1989 merged 3 commits intomainfrom
jryan/ready-to-verify-presenter-flaky-test
Dec 1, 2023
Merged

Address ready_to_verify_presenter_spec flaky tests.#9652
JackRyan1989 merged 3 commits intomainfrom
jryan/ready-to-verify-presenter-flaky-test

Conversation

@JackRyan1989
Copy link
Contributor

What does this pull request fix?

The time zone for the due date calculation for in_person_enrollment shifts ahead one hour very rarely. Seemingly always on 9/12/22 and always between -400 and -300.

Start date: 2022-08-13 20:00:00 -0400
Due date: 2022-09-12 20:00:00 -0300

This causes test flakiness in ready_to_verify_presenter_spec.rb.

This corresponds pretty well to when Chile decided to delay the start of DST:
https://www.timeanddate.com/news/time/chile-dst-delay-2022.html

🛠 Summary of changes

  1. Change the created_at and enrollment_established_at dates to avoid issues with DST across all timezones.
  2. Remove unneeded .utc to keep timezones consistent.

Testing:

  1. Run the spec a whole bunch of times locally. I suggest using this until_fail script to run the spec over and over.

Note:

I think this code is still buggy. These changes should remove the flakiness with this particular test, but we need to handle date calculation for when DST strikes and the distance between days increases or decreases by an hour.

@JackRyan1989 JackRyan1989 requested review from a team and soniaconnolly November 22, 2023 20:51
@JackRyan1989 JackRyan1989 self-assigned this Nov 22, 2023
let(:created_at) { described_class::USPS_SERVER_TIMEZONE.parse('2023-06-14T00:00:00Z') }
let(:enrollment_established_at) do
described_class::USPS_SERVER_TIMEZONE.parse('2022-08-14T00:00:00Z')
described_class::USPS_SERVER_TIMEZONE.parse('2023-07-14T00:00:00Z')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The purpose of these changes is not obvious to me. Was this ultimately just to get us away from an edge-of-DST-change date?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's exactly the case. As far as I can tell, September 11- September 12th is DST change for UTC -300. So changing by a year and a month.

Copy link
Contributor

@soniaconnolly soniaconnolly left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks for tracking this down! As you noted, the code should probably also be changed to be less sensitive to DST.

@JackRyan1989 JackRyan1989 requested a review from n1zyy November 29, 2023 14:46
@JackRyan1989 JackRyan1989 merged commit ab91f3b into main Dec 1, 2023
@JackRyan1989 JackRyan1989 deleted the jryan/ready-to-verify-presenter-flaky-test branch December 1, 2023 16:30
@solipet solipet mentioned this pull request Dec 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants