- Shipped
- October 5, 2026 at 5:01 PM UTC
- Author
- Kamo
- Commit
- 425f241
listCalendars provisions the shared and the personal calendar find-then-create, each in its own transaction, and treated a lost race as done only when it surfaced as a unique violation. On Yugabyte the losing write can instead fail with 40001 ("could not serialize access due to concurrent update"): Loki shows three such 500s on CalendarWidgetController.events in a week (2026-10-01 23:27:31Z on both pods at once, 2026-10-02 03:51:58Z), from the launchpad's two widgets loading together. A ConcurrencyFailureException now takes the step once more, in a new transaction whose find sees the winner's row; a second conflict is logged and left for the next load, and the listing still answers. Tests: **************** +2 (RED: CannotAcquireLockException escaped listCalendars).