Fix calendar window overshooting the cached year range

Found by probing the running API; both suites were green and missed it.

CalendarService validated only start_year against the cache, never the window
end. GET /api/calendar/days?start_year=2035&years=4 returned 200 with
end_year=2038, pulling 2036-2038 from the live holidays-library fallback in
app/utils/holidays.py. That fallback does not know the de facto free days, so
Julafton, Nyarsafton and Midsommarafton were reported as ordinary working days
(18 red days per cached year vs 13 per uncached year). Julafton being charged
as a working day was fixed once before; it had reappeared past 2035.

- clamp end_year to max_year; the response now always reports what it returned
- add strict=True to get_swedish_holidays/get_red_days plus UncachedYearError,
  checked before the memo cache, so a strict caller fails loudly rather than
  silently degrading. Non-strict default behaviour is unchanged.
- RedDaysList derived endYear locally as startYear + years - 1, independent of
  the response, so a clamped window rendered phantom empty years. It now takes
  endYear from the backend.

Tests: clamping at and before max_year (service + router), Julafton/Nyarsafton/
Midsommarafton red for every cached year, red-day count consistent across the
served range, and strict-mode raise/pass-through.

Backend 404 -> 414 tests, frontend 704 -> 705.

Known, deliberately not fixed here: AllocationInputLoader builds its holiday map
the same non-strict way over the planning horizon, so it has the same exposure
once the horizon passes 2035. Clamping would silently truncate planning and
raising would break real plans, so it needs a product decision first.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RXMhc9nT6sNz1SL4j8dznL
This commit is contained in:
2026-09-14 02:46:47 +02:00
parent 17dadb79cc
commit 28c632ca36
8 changed files with 295 additions and 8 deletions
+24 -4
View File
@@ -8,8 +8,14 @@ UI can show what the app actually treats as free, not just the statutory
calendar.
No runtime external API calls (§6): everything here reads the pre-built
cache (or, outside its range, the local `holidays` library) via
`app.utils.holidays`.
cache via `app.utils.holidays`. The requested window is clamped to the
cache's [min_year, max_year] (see `get_calendar_window`) and every lookup
uses `strict=True`, so this endpoint can never silently fall back to the
local `holidays` library for a year the cache doesn't cover — that fallback
only knows formal röda dagar (+ every Sunday), not de facto days or
klämdagar, and serving it unlabelled here previously caused a real bug
(Julafton/Nyårsafton/Midsommarafton silently reading as working days past
the cache's end).
"""
from __future__ import annotations
@@ -93,13 +99,27 @@ class CalendarService:
)
end_year = start_year + years - 1
if max_year is not None and end_year > max_year:
# Clamp rather than 422: the response already carries min_year/
# max_year for the UI's paging bounds, so the last page is
# naturally shorter than `years` requested. `end_year` below
# reports the ACTUAL clamped range — never a range not returned.
end_year = max_year
overrides = await self._day_override_service.get_effective_map(workspace_id)
days: list[CalendarDay] = []
for year in range(start_year, end_year + 1):
holidays_map = get_swedish_holidays(year)
red_days = get_red_days(year)
# `strict=True`: after the clamp above, every `year` here is
# guaranteed inside [min_year, max_year], so this must never hit
# the live-`holidays` fallback. If it ever does, that's a bug in
# the clamping above, not bad input — fail loudly (see
# `app.utils.holidays.UncachedYearError`) rather than silently
# serving degraded data for this endpoint (the actual bug this
# guards against: years past the cache losing Julafton,
# Nyårsafton, Midsommarafton).
holidays_map = get_swedish_holidays(year, strict=True)
red_days = get_red_days(year, strict=True)
day = date(year, 1, 1)
one_day = timedelta(days=1)
while day.year == year: