[xwiki-notifications] [xwiki/xwiki-platform] 8e31e9: [Misc] Fix race condition blocking ExtensionSecuri...

Branch: refs/heads/master Home: https://github.com/xwiki/xwiki-platform Commit: 8e31e99ee4182e3b23176317211774d912a3ee3b https://github.com/xwiki/xwiki-platform/commit/8e31e99ee4182e3b231763172117… Author: Michael Hamann <michael.hamann(a)xwiki.com> Date: 2025-07-18 (Fri, 18 Jul 2025) Changed paths: M xwiki-platform-core/xwiki-platform-extension/xwiki-platform-extension-security/xwiki-platform-extension-security-index/src/main/java/org/xwiki/extension/security/internal/ExtensionSecurityScheduler.java M xwiki-platform-core/xwiki-platform-extension/xwiki-platform-extension-security/xwiki-platform-extension-security-index/src/test/java/org/xwiki/extension/security/internal/ExtensionSecuritySchedulerTest.java Log Message: ----------- [Misc] Fix race condition blocking ExtensionSecuritySchedulerTest * Fix a race condition where the future returned by `ExtensionSecurityScheduler#start()` would never be completed because it was null when the executor executed the runnable. This can block the execution of ExtensionSecuritySchedulerTest, causing it to hang infinitely. In actual use, this could only happen when the extension security scan is disabled as otherwise, the actual scan takes so much time that it's unlikely that the completable future hasn't been initialized in the meantime. Even for the disabled case, it seems very unlikely and most likely not that problematic as the only code waiting for the completable future seems to be testing code. It would prevent the scheduler from executing again after 24h, but the only use case where this would matter is if the scheduler was first disabled and then re-enabled. * Make ExtensionSecurityScheduler more robust by making `restart()` synchronized, too. * Bulletproof the test by only waiting 20 seconds for the future to be completed. To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-platform/settings/notifications