18 Jul
2025
18 Jul
'25
10:18 a.m.
Branch: refs/heads/stable-17.4.x
Home: https://github.com/xwiki/xwiki-platform
Commit: 8a766a69ad1b3650cb35840563cbee846378879e
https://github.com/xwiki/xwiki-platform/commit/8a766a69ad1b3650cb35840563cb…
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.
(cherry picked from commit 8e31e99ee4182e3b23176317211774d912a3ee3b)
To unsubscribe from these emails, change your notification settings at
https://github.com/xwiki/xwiki-platform/settings/notifications