What a Spring Boot Static Analyzer Missed About Hidden Database Calls

An engineer building a static analyzer to trace what an endpoint change touches in a Spring Boot codebase found that every serious bug shared the same shape: confident false negatives claiming no database access, no transaction, or no message publishing — when all three occurred. The root cause was that Spring executes code nothing in the source visibly calls, which a handler-first, call-graph-walking read of the code simply cannot see.

Measured against real repositories, the failures were substantial. Interface-based request mappings (common with OpenAPI-generated or shared API contracts) hid entire route sets from annotation scans. Functional routing via RouterFunctions was invisible to any annotation-based approach. @ModelAttribute methods run before every handler but have no call site to trace. Spring Data's synthesized repository methods (save, findById) exist in no source file at all. Class-level @Transactional wasn't detected by method-level scanning, causing the tool to recommend wrapping writes in a transaction the code already had.

Application events, work handed off to executors, and messaging boundaries (SQS, RabbitMQ) produced similar blind spots: queue identifiers appear in multiple forms, annotation-free consumers predating spring-cloud-aws go undetected, and RabbitMQ's exchange/routing-key model can't be joined on a destination string at all. Misreading JPQL as SQL also caused keywords like FETCH to be mistaken for table names.

The broader lesson applies beyond tooling: both static analyzers and human pull-request reviewers following call chains from a handler risk missing Spring's implicit framework-level behavior — interface mappings, class-level transactions, event listeners, and executor-dispatched work. A tool or reviewer reporting 'nothing found' is often reporting its own blind spot, not the absence of the behavior.