- Shipped
- September 23, 2026 at 2:40 PM UTC
- Author
- Kamo
- Commit
- 9fc87cc
Caller half of the kamo-shared-library fix: switches every findById() call on LeadVendorProductRepository in securityservice to whichever lean method matches what it actually reads (see **************** / findByIdWithVendor's javadoc for the full reasoning and the production numbers — an 8-way join measured at ~780K calls, 10-21ms, on what is always a single-id lookup, never a batchable N+1). - LeadController.isFreeForAllLead (every unassigned-lead view and history read): findIsEmptyCreditFfaById — a scalar projection, the only field this ever reads. - **************** LeadCreditController's distribute/updateAllotment: findByIdWithVendor — these read vendor.org.id or hand the vendor object on; nothing past vendor. - **************** (public, unauthenticated): findByIdWithVendor plus a second, ordinary LeadMarketRepository.findById() for the market and its organisation — the two-query split this codebase already uses to reach a JOINED-inheritance entity safely (LeadMarket->Organization) without an @EntityGraph across the JOINED boundary. LeadAcceptController's inject-test-lead and set-ffa endpoints (both MANAGE_CREDITS-gated, low volume) are left on findById() — lower priority given the call volume this addresses is overwhelmingly the read paths above, and flagged in the report rather than guessed at further. JSON shapes are unchanged.