apps/stats/test/unit/hooks/use-growth-stats.test.tsx (1)

282-322: New MRR edge‑case test accurately captures the regression scenario

This test does a good job of reproducing the “no data before dateFrom, sparse data inside range” case and verifying the synthetic start point behavior. Overriding mockedGetRangeDates to return the same startDate used for dateFrom keeps the assertion stable and decoupled from getRangeDates’ internal implementation, and the expectations on mrrData[0].date and mrrData[0].mrr directly guard against the original $0 at range start bug.

If you want to tighten readability slightly, you could extract 17286 into a named constant (e.g., const INITIAL_MRR = 17286;) and reuse it in the data + assertion, but that’s purely cosmetic.

apps/stats/src/hooks/use-growth-stats.ts (1)

299-306: Earliest-in-range fallback correctly fixes missing start-point case; verify impact on MRR % change and consider minor refactor

The new else if (result.length > 0) branch is the right fix for the sparse-history scenario the PR describes: when there’s no data before dateFrom but there is data inside the range, you now prepend a synthetic point at dateFrom using the earliest in-range MRR value. That ensures the chart no longer starts at $0 and aligns with the new test.

Two follow‑ups to consider:

1. Behavioral interaction with MRR percent-change logic

   calculateTotals derives percentChanges.mrr from mrrData and has special handling for “from beginning” ranges (isFromBeginningRange) where it previously assumed a starting value of 0 when there was no data exactly at dateFrom. With this change, any range that has at least one in-range MRR point will now have a synthetic dateFrom entry, so that “assume started from 0” branch may never run in practice. That effectively changes MRR percent‑change semantics for from‑beginning ranges to use the earliest available MRR instead of 0.

   Please double‑check this against product expectations; if YTD/beginning‑of‑time ranges are still meant to show “0 → current” style growth when historical data is incomplete, you might want to explicitly distinguish synthetic vs. real points or adjust the calculateTotals logic accordingly.

2. Minor efficiency/readability tweak (optional)

   To obtain earliestInRange, you currently sort a copy of result:

   const earliestInRange = [...result].sort((a, b) => new Date(a.date).getTime() - new Date(b.date).getTime())[0];

   Given result is typically small, this is fine; but you could avoid the extra sort by computing the earliest in a single pass:

   let earliestInRange = result[0];
   for (const item of result) {
       if (new Date(item.date).getTime() < new Date(earliestInRange.date).getTime()) {
           earliestInRange = item;
       }
   }

   Functionally identical, slightly clearer that we’re just looking for the min date.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: CR
Repo: TryGhost/Ghost PR: 0
File: e2e/AGENTS.md:0-0
Timestamp: 2025-11-24T17:29:43.865Z
Learning: Applies to e2e/**/*.test.ts : Use factory pattern for all test data creation instead of hard-coded data or direct database manipulation