Spring Data Fragment Scan CrashLoop

Symptom

The backend pod crash-loops during startup with a repository bean failure that ends in a query-derivation message such as No property 'filter' found for type ....

The historical incident is preserved in the current smoke-test comment at lumie-backend/app/src/test/java/com/lumie/app/ApplicationContextLoadsTest.java, which references a StaffRepositoryCustomImpl that lived outside the repository interface package.

Likely Cause

Spring Data could not discover the custom fragment implementation, so the repository method fell through to method-name query derivation.

This commonly happens when:

• the fragment interface lives under domain/repository;
• the implementation lives under adapter/out/persistence;
• the implementation is neither in the scanned package path nor exposed as a Spring bean.

Diagnosis

Read the stack trace as a Spring Data fallback sequence, not as a field-mapping problem:

1. If the parser complains about a missing property named after your repository method, fragment resolution already failed.
2. Confirm whether the custom implementation is in the same package subtree as the repository interface.
3. Confirm whether the implementation is also a Spring bean.
4. Run the full-context smoke test, not just module @DataJpaTest slices.

The current regression guard is:

• lumie-backend/app/src/test/java/com/lumie/app/ApplicationContextLoadsTest.java
• lumie-backend/app/src/test/java/com/lumie/app/FullContextTestBase.java

Those tests exist specifically because narrower slices did not exercise full repository-proxy construction across the monolith.

Fix

• Add @Component to the cross-package fragment implementation, or
• move the implementation into the repository interface package subtree, or
• explicitly widen repository implementation scanning if the architecture requires split packages.

The 2026 incident used the first option as the stopgap and then added the full-context smoke test so the same failure would block CI instead of production.

Prevention

• Treat custom repository fragments as boot-time wiring risk, not just a persistence detail.
• Keep at least one @SpringBootTest(classes = LumieApplication.class) smoke test in the default test graph.
• When a fragment implementation crosses package boundaries, make the discovery rule explicit instead of relying on convention.

Source Incident Detail

The May 21, 2026 source incident was a production CrashLoopBackOff caused by Spring Data repository fragment discovery. Narrow repository-slice tests missed it because they did not construct the full monolith repository graph.

Detail	Value
Symptom	application startup failed before serving traffic
Exception class	PropertyReferenceException in the source record
Immediate root cause	fragment implementation was not discovered where Spring Data expected it
Stopgap	add @Component to the cross-package fragment implementation
Regression guard	full application context smoke test

The diagnostic trap is that Spring Data can interpret a missing fragment implementation as a derived-query method. That makes the final exception look like a property-name problem even though the real issue is repository fragment wiring.

The source record also explains why existing tests missed it:

Existing test type	Why it missed
per-module @DataJpaTest slices	only loaded module-local repositories
routing datasource integration test	deliberately used an empty repository package
web-layer tests	mocked or skipped the JPA layer

The retained prevention is a full @SpringBootTest(classes = LumieApplication.class) context test that exercises repository proxy construction across the monolith.