royteeuwen opened a new pull request, #222: URL: https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/222
`AliasMapEntriesTest.test_event_alias_during_bg_init[isOptimizeAliasResolutionEnabled=true,isAliasCacheInitInBackground=true]` is flaky. It has failed on the 2.0.4 `release:perform` run and twice on a recent 1.x PR build, with two different symptoms: - `org.mockito.exceptions.misusing.WrongTypeOfReturnValue: Resource$MockitoMock cannot be returned by findResources()` at `createMockedResource` - `Alias Map Entry for /top should contain an entry for leaf2 ... but got: null` Both come from the same cause. The test parks the background init thread inside the `findResources` answer (`greenLight.await()`) and then, while that thread is live, keeps stubbing the shared `resourceResolver` mock — `createMockedResource(top, "leaf2")` and `removeResource(leaf1)` both call `when(resourceResolver.getResource(...))`. Mockito keeps the invocation being stubbed on the mock's own invocation container, not per thread, so if the bg thread enters `findResources` between the main thread's `getResource(path)` call and its `.thenReturn(result)`, the stub binds to `findResources` instead. Depending on where it lands that either throws `WrongTypeOfReturnValue` or silently drops the stub, leaving `leaf2` unresolvable so its alias never reaches the map. The fix moves all mock setup ahead of `initializeAliases()`, leaving only `onChange(...)` calls inside the concurrent window — the same shape `VanityPathMapEntriesTest.test_remove_vanity_path_during_bg_init` already uses. The test still exercises what it did before: `findResources` is stubbed to return the pre-removal snapshot (`leaf1` only), so the events remain the only route by which `leaf1` leaves the alias map and `leaf2` enters it. ### Verification Repeated runs of `AliasMapEntriesTest` on this machine: | | result | |---|---| | before (unmodified `master`) | 29 pass / **1 fail** in 30 runs | | after | 60 pass / 0 fail in 60 runs | Full `mvn clean verify`: BUILD SUCCESS, 645 tests, 0 failures. Given the failure is a scheduling race, 60 clean runs is evidence rather than proof — but the mechanism above is deterministic, and the remaining window contains no stubbing at all. -- 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]
