KamoCRM

Stop two first loads provisioning two of each calendar

FixEmailService
Shipped
26 ஆகஸ்ட், 2026 அன்று 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.

All changes

Like what you see shipping?

All of it arrives in your workspace on its own. Start on the free plan and read this page again in a month.

Start Free ForeverView Pricing