1d4bcd5082
## Sentry Fixes **[PHP-LARAVEL-3A](https://whisper-money.sentry.io/issues/PHP-LARAVEL-3A)** — `FatalError: Maximum execution time of 30 seconds exceeded` on `GET /api/cashflow/trend`. Top frame in Carbon date math (`getUTCUnit`). ## Root cause `trend()` caps the `months` param at 24, but the `from`/`to` branch validated only `date` — **no span limit**: ```php if (isset($validated['from'], $validated['to'])) { $start = Carbon::parse($validated['from'])->startOfMonth(); $end = Carbon::parse($validated['to'])->endOfMonth(); } ``` The series is then built by `while ($current->lte($end)) { ...; $current->addMonth(); }`. A request with a huge range (e.g. `from=0001-01-01&to=9999-12-31`) runs that loop hundreds of thousands of times — each iteration doing Carbon `format()`/`addMonth()` — and exhausts the 30s timeout. (Sentry strips query strings, which is why the captured URL looked param-less.) The frontend uses the capped `?months=12&to=...` path for the month view, but the uncapped `?from=...&to=...` path for other period types. ## Fix Clamp the computed `start` to at most `MAX_TREND_MONTHS` (24) months before `end`, regardless of branch. Bounds both the month loop and the transaction query window. 24 matches the existing `months` ceiling. ## Test `cashflow trend caps the window for unbounded date ranges` — requests `from=0001-01-01&to=9999-12-31` and asserts exactly 24 data points returned, in ~0.02s. Without the clamp this loops ~96k months and hangs. |
||
|---|---|---|
| .. | ||
| .pest | ||
| Browser | ||
| Feature | ||
| Performance | ||
| Support | ||
| Unit | ||
| Pest.php | ||
| TestCase.php | ||
| bootstrap.php | ||