- Ya
- 14 Agosti 2026, 15:13 UTC
- Mwandishi
- Kamo
- Ahadi ya
- c1e68a9
The calendar page could never list anything. It asks for every event a member has, with no window, and these queries took the range as nullable and tested it with (:start IS NULL OR e.startTime >= :start). With a null argument the driver sends an untyped parameter and PostgreSQL refuses the statement: ERROR: could not determine data type of parameter $3 So /api/calendar/events answered 500 on every request, and the page rendered an empty grid with no indication anything had gone wrong. Deleting a calendar hit the same fault, from findByCalendarInRange(id, null, null). Each lookup now takes a required window and is fronted by a default that widens an absent bound, so a typed value is always sent and no database-specific cast is needed. The bounds are year 1 and year 9999 rather than Long.MIN_VALUE, because PostgreSQL timestamps stop at 4713 BC and a sentinel outside the column's range fails exactly the way the null did. Verified against Yugabyte: the bounded form returns the events the null form could not ask for.