- Shipped
- September 5, 2026 at 7:49 PM UTC
- Author
- Kamo
- Commit
- aea785e
Same defect as the sign-in fix, found by reading the fleet's logs rather than one report: eight hours of pod logs across email, media, docs, daemon and security name the exact statement each conflict started on. Three of those origins live here, and each is a read shared by every service. AppliedModelEnforcementService was the most frequent origin in SecurityService. Both of its callers already survive a bump, but only by giving up on the answer: AppAvailabilityInterceptor fails open, and OrganizationController logs "Auto- provisioning / projection failed" and degrades to no features. That is the login page's own branding endpoint quietly returning an organization with its apps missing. Retrying gets the real answer instead of a safe wrong one. **************** is where MediaService's conflicts landed. It is private, so the annotation goes on the three public methods that reach it; a note now says so, because a stack trace points at the method that cannot carry it. LeadService.getLeadGridPage covers resolveAssignees with it — the grid's own transaction, so one annotation is the whole path. Deliberately NOT AppliedModelResolverService, which is where the failing statement actually is. **************** already retries and reaches it through applyTemplateRules, so annotating it too would nest one retry inside another and turn three attempts into nine on the busiest path in the platform. The enforcement service is the seam that covers the uncovered callers without touching the covered one. 2778 tests green.