- Shipped
- September 5, 2026 at 6:23 AM UTC
- Author
- Kamo
- Commit
- 59c815d
The member-by-id load is close to the first statement an authenticated request performs, so a catalog-version bump hits it before it hits anything else. That is why the last window was reported as "the scoreboard widget cannot be reached": the query that actually failed was a boring identity load shared by nearly every endpoint, and whichever feature announced its own failure loudest got the blame. Annotated here rather than at the 96 memberRepository.findById call sites in SecurityService, none of which is a chokepoint and most of which sit inside @Transactional methods where a retry would do nothing at all. These four reads are in the shared library, so one place covers the fleet. The retry is meaningful on exactly these methods because they are NOT @Transactional: each repository call runs in its own implicit transaction, so a second attempt genuinely gets a new one — the same reason it works in OrgResolutionService. Adding @Transactional to any of them later without moving the retry outwards with it would quietly turn these into no-ops. Reads only. Retrying a read is safe by inspection; the write paths on this class are left alone. The test asserts the annotation is IN FORCE on the real class through a real proxy, not that the retry helper works. It failed with the raw conflict until the context registered an auto-proxy creator, which is worth knowing: without one, the bean comes out unproxied and every annotation on it is inert while looking perfectly correct. Not covered: member.getOrganization(), which is a LAZY dereference resolved later under open-in-view, outside any method an annotation can wrap.