Skip to content

Fix flaky epics_finder_spec race condition

Dylan Griffith requested to merge 321511-fix-epicsfinder-flaky-test-timing-issue into master

What does this MR do?

As per #321511 (closed) we've seen one of these tests fail. It seems likely the problem is caused by the use of X.days.ago throughout and then filtering with date ranges. The likely explanation is that when the test is running just before midnight then 2.days.ago actually ends up being "3 days ago" from a date perspective by the time the assertion is made about it.

Even though it's not easy to replicate this exact failure mode and this flakiness has never happened for this spec before (to my knowledge) in 3 years it still is not a good way to write these kinds of tests as this is theoretically a problem.

Instead of making all the times relative to "now" (which changes) I've just made everything relative to some arbitrary fixed time. This works fine, without any need for freezing time, as none of the methods being tested actually refer to the current time.

The test is still quite difficult to read due to many different dates and times and the fact that the examples are separated from the test setup but I don't think this change makes it less clear.

Screenshots (strongly suggested)

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • Label as security and @ mention @gitlab-com/gl-security/appsec
  • The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
  • Security reports checked/validated by a reviewer from the AppSec team

Related to #321511 (closed)

Edited by Dylan Griffith

Merge request reports