Test flakiness: MeterReadingControllerTest.shouldReturn200WhenExists (Spring context bootstrap)

[dfcoffin]

Summary

MeterReadingControllerTest.shouldReturn200WhenExists exhibits Spring-context-bootstrap flakiness: it failed once in CI on PR #116 and passed on retry with no code change.

Distinct from #78 (cross-platform timestamp-resolution flakiness) — this one is context-bootstrap timing, not timestamp precision.

Action

• Reproduce (run the test repeatedly, e.g. mvn test -pl openespi-datacustodian -Dtest=MeterReadingControllerTest#shouldReturn200WhenExists -Dsurefire.rerunFailingTestsCount=0 in a loop).
• Identify the bootstrap race — likely shared mutable context state, @MockBean re-init, or an ordering dependency between tests in the class.
• Fix the root cause (proper test isolation / @DirtiesContext only if unavoidable), not by adding blanket retries.

Acceptance criteria

• Root cause identified and documented
• Test passes deterministically across repeated runs
• No reliance on CI retry to go green

Source

PR_116_FOLLOWUP_NOTES.md item 4 (post-PR #116, 2026-05-19).

[dfcoffin]

Closing as resolved. The flakiness root cause was the StreamingResponseBody × Spring Security OnCommittedResponseWrapper ConcurrentModificationException (see #119 Phase 1). De-streaming is now complete on main — there are 0 StreamingResponseBody references left in the DataCustodian controllers, so the race that caused MeterReadingControllerTest.shouldReturn200WhenExists to fail no longer exists. The test has been green across every recent CI run (#163/#164/#165). Reopen if it recurs.