Branch: refs/heads/master Home: https://github.com/xwiki/xwiki-platform Commit: c28327d554a177476c939354a5f968f73e8c44aa https://github.com/xwiki/xwiki-platform/commit/c28327d554a177476c939354a5f96... Author: Michael Hamann <[email protected]> Date: 2026-09-16 (Wed, 16 Sep 2026) Changed paths: M xwiki-platform-core/xwiki-platform-xclass/xwiki-platform-xclass-test/xwiki-platform-xclass-test-docker/pom.xml M xwiki-platform-core/xwiki-platform-xclass/xwiki-platform-xclass-test/xwiki-platform-xclass-test-docker/src/main/java/org/xwiki/xclass/test/XClassVisibilityTestScriptService.java M xwiki-platform-core/xwiki-platform-xclass/xwiki-platform-xclass-test/xwiki-platform-xclass-test-docker/src/test/it/org/xwiki/xclass/test/ui/XClassCacheVisibilityIT.java Log Message: ----------- XWIKI-24997: XClass is cached as non-existing or outdated when it is saved while a document using it is being loaded (MySQL/MariaDB) * rewrite XClassCacheVisibilityIT to decide by ordering instead of by timing: the loading thread opens a store transaction and forces its database snapshot, the main thread then saves the XClass, and only then does the loading thread load a document using it. Latches order those steps, so the test reproduces the problem or doesn't, the same way on every machine. * cover both halves of the issue: an XClass created while the document loads, which ends up cached as non-existing, and one that gains a property while the document loads, which ends up cached without it. * wait for the asynchronous work a save triggers - the tasks consumer and the Solr indexer - and empty the document cache before loading, so that the loading thread is the only reader of the XClass. The previous version raced two threads and swept a delay across the measured duration of a document load, whose length it set with 400 filler XClasses. It reproduced the problem locally in 12 of 20 rounds but not at all on CI: there the sweep found nothing on MySQL with a 454 ms window, and on PostgreSQL the window guard failed the test for being too fast rather than for the bug. It had two timing dependencies rather than one: the save has to commit between the snapshot and the resolution of the class, and the class has to be read from the database rather than from the document cache - which the asynchronous work following the save re-fills within milliseconds, from its own newer transaction. Both are now preconditions the test establishes instead of races it has to win, which also makes it cheap: a few seconds rather than the minute the sweep needed, and no filler documents at all. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-platform/settings/notifications