- Shipped
- August 26, 2026 at 11:20 PM UTC
- Author
- Kamo
- Commit
- c9d3ba4
The launchpad paints two calendar widgets and each fetches its own feed, so two requests reached listCalendars at once. Provisioning is find-then-create, both passed the find, and both inserted: seven organisations hold two "Organization Calendar" rows and thirteen members two "My Calendar" rows, each pair written microseconds apart. /calendar listed every one of them. Provisioning moves to its own bean so the calls go through Spring's proxy, and listCalendars now suspends its transaction. That is what makes recovery possible: a partial unique index per calendar kind (KI, landing separately) turns the second insert into a violation rather than a row, and re-reading after the winner commits only finds it in a NEW transaction — this cluster hands a transaction one snapshot for its whole life, so a second look inside the failed one would still see nothing. Callers inside a transaction of their own — InternalCalendarService writing a lead callback — still join it, so the calendar and its event commit together.