nick-boss-tech opened a new pull request, #5029: URL: https://github.com/apache/solr/pull/5029
🤖 *AI text below* 🤖 *(posted on behalf of Nick Shanin)* https://issues.apache.org/jira/browse/SOLR-18506 ## What happens today org.apache.solr.search.TestThinCache.testSimple fails intermittently with "expected:<0> but was:<1>" at the second cache's evictions assertion, together with a classMethod teardown error reporting 3 unreleased SolrMetricsContext objects (a knock-on: the failed assertion skips the test's closing of its metrics context). It was recorded 14 times in 30 days across unrelated PRs, ten of them on branch_9x, and the value is exactly 1 on every occurrence. In the test, the second cache warms from the first into a shared backing cache that stays at its 100-entry capacity: warming puts 25 entries and the test then puts key 103, and every such put evicts an entry. When an eviction victim belongs to the second cache's scope, ThinCache.onRemoval counts it in that cache's evictions metric; whether such a delivery has landed by the time the metric is sampled at the end of the test is timing dependent. That is the flake. ## What this change does Test-only, one file. After the first cache's assertions, the test enlarges the shared backing cache through the existing public CaffeineCache.setMaxSize(200). Both phases together hold at most 126 distinct entries, so nothing is evicted during the warming phase under any interleaving, and the second cache's eviction count is deterministically 0; setMaxSize also runs Caffeine cleanUp, settling maintenance pending from the first phase. The first cache's single overflow eviction (key 1) never enters this count: in this test the first cache is not registered as a removal listener (registration happens in initForSearcher, which only the second cache's warm call triggers), so its counter stays 0 and the priors copied by warm contribute 0. The eviction assertion itself is unchanged and keeps its meaning, now sampled at a point where the value cannot race. A bounded poll for a settled value was considered and rejected: while the second phase can still evict, there is no exact settled valu e to poll for, because post-warm evictions are attributed per scope. ## Proof The failure does not reproduce locally: all 14 recorded seeds passed on unmodified main during planning, and the race needs a loaded CI runner's timing, so there is no honest local before/after pair. Proof on this head is a forced re-execution seed battery (cleanTest, full class, 2 tests per run), verified 2026-10-05 at 3c098439882: all 14 recorded seeds pass; 3 default-seed runs pass; 3 extra repeats of each of the four most recent seeds pass (12 runs); 3 runs under CPU load pass; 32 of 32 runs green. Neighbor suite TestCaffeineCache 6/6. Gate: tidy clean, Error Prone :solr:core:compileTestJava clean, :solr:core:check -x test green. No changelog entry: test-only fix. ## Limits This lands on main only. Ten of the fourteen recorded occurrences were on branch_9x (solrbot PR #4976), where the test's metrics accessors have the older shape; the same fix shape applies there but the accounting needs its own read first. Happy to prepare a branch_9x backport PR on request. The warming phase no longer exercises eviction pressure against a full shared backing; that crosstalk's per-scope eviction attribution is nondeterministic, so no exact assertion could cover it, and if maintainers want warm-under-pressure coverage it belongs in a separate test designed around ranges or totals. ### AI assistance AI agents assisted with research, implementation, review, and drafting. Nick Shanin directed the work and takes responsibility for this contribution. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
