- Shipped
- September 5, 2026 at 3:53 PM UTC
- Author
- Kamo
- Commit
- 8ccc080
Member.organization is LAZY, so findById left a proxy behind and the real SELECT happened whenever something first dereferenced it. Under open-in-view that is typically while a controller builds its response — outside the service method, outside the transaction, outside anything a retry can wrap. A catalog-version bump landing on that statement is therefore unrecoverable, which is why member.getOrganization() showed up in the last outage right beside the member load itself, and why annotating the read alone did not actually cover it. Fetching the organization with the member moves that dereference inside the retried call. It also removes the follow-up SELECT, so this is not a second query added — it is a second query stopped from happening at the worst possible moment. LEFT JOIN FETCH, not an inner join. The column is NOT NULL today, which makes LEFT free; it is also the version that stays correct if that ever stops being true, where an inner join would silently drop the member and report "no such member" for what is really a missing organization row. This repository already had to learn that lesson once — see the aliased user join in findByOrganizationId. The test now stubs findByIdWithOrganization rather than findById, so it pins that getMemberById uses the fetching query and not just any query. 2758 tests green.