[Flaky Test] SubscriptionUtils › isUserOnFreeTrial › should return true if the current date is on the same date of free trial start date

[MelvinBot]

Flaky Test

tests/unit/SubscriptionUtilsTest.ts intermittently fails on:

SubscriptionUtils › isUserOnFreeTrial › should return true if the current date is on the same date of free trial start date

FAIL tests/unit/SubscriptionUtilsTest.ts
  ● SubscriptionUtils › isUserOnFreeTrial › should return true if the current date is on the same date of free trial start date
      at Object.toBeTruthy (tests/unit/SubscriptionUtilsTest.ts:200:76)

Test Suites: 1 failed, 116 passed, 117 total
Tests:       1 failed, 2 skipped, 1917 passed, 1920 total

Seen on: Expensify/App#93054 — test (job 7) (unrelated PR; the failure has nothing to do with that PR's changes).

Likely cause

The test depends on the real system clock rather than fake timers. It captures firstDayFreeTrial from new Date() and then calls isUserOnFreeTrial(...), which re-reads new Date() at call time:

tests/unit/SubscriptionUtilsTest.ts:192-201

Because the two new Date() reads happen at slightly different moments (and can straddle a second/minute/day boundary), the free-trial window comparison can evaluate to false, so the toBeTruthy() assertion fails non-deterministically.

Suggested fix

Freeze time in this suite (e.g. jest.useFakeTimers().setSystemTime(...) or inject a fixed "now") so the boundary date/time comparisons are deterministic, then restore real timers in teardown. The same clock-dependent pattern applies to the sibling isUserOnFreeTrial cases, so consider stabilizing them together.

This is a pre-existing flaky test, not a regression from any specific PR.

[MonilBhavsar]

@MelvinBot can we simply sleep in test so timestamps are not same?

[MelvinBot]

Yes, a sleep would fix this specific test — but there's a smaller, fully-deterministic change that's better.

Why a sleep works: The suite writes firstDayFreeTrial as formatDate(new Date(), 'yyyy-MM-dd HH:mm:ss') (SubscriptionUtilsTest.ts:193), which truncates to whole seconds. isUserOnFreeTrial then re-reads the clock and requires isAfter(currentDate, firstDayFreeTrialDate) — a strict comparison (SubscriptionUtils.ts:409-415). The only way it fails is when both new Date() reads land on the exact same instant with .000 ms, so the truncated start equals currentDate and "strictly after" is false. Any forward time movement — including a sleep — breaks that tie.

Why I'd not use sleep: it adds real wall-clock delay to the suite and is still a timing-based fix. The cleaner option is to just offset the start timestamp into the past so isAfter is robustly true, which also matches what the sibling end-date case already does with addMinutes(new Date(), 30):

const firstDayFreeTrial = formatDate(subMinutes(new Date(), 1), CONST.DATE.FNS_DATE_TIME_FORMAT_STRING);

This keeps the test's intent ("trial started, we're inside the window → truthy"), removes the flake with zero added runtime, and needs no fake-timer setup/teardown.

Note: freezing time alone (jest.setSystemTime(...)) is not sufficient here — if the frozen instant has .000 ms, firstDay === currentDate and the strict isAfter still fails. Whatever approach you pick, the start date must be strictly before "now".

---

Next Steps: Reply with @MelvinBot implement this to open a draft PR with the subMinutes fix, or @MelvinBot <feedback> to adjust.