Branch: refs/heads/stable-18.8.x Home: https://github.com/xwiki/xwiki-platform Commit: 98173ed6d67032a4b7dec91662ad7824d52b20a0 https://github.com/xwiki/xwiki-platform/commit/98173ed6d67032a4b7dec91662ad7... Author: Michael Hamann <[email protected]> Date: 2026-09-17 (Thu, 17 Sep 2026) Changed paths: M xwiki-platform-core/xwiki-platform-xclass/xwiki-platform-xclass-test/xwiki-platform-xclass-test-docker/pom.xml A xwiki-platform-core/xwiki-platform-xclass/xwiki-platform-xclass-test/xwiki-platform-xclass-test-docker/src/main/java/org/xwiki/xclass/test/XClassVisibilityTestScriptService.java A xwiki-platform-core/xwiki-platform-xclass/xwiki-platform-xclass-test/xwiki-platform-xclass-test-docker/src/main/resources/META-INF/components.txt M xwiki-platform-core/xwiki-platform-xclass/xwiki-platform-xclass-test/xwiki-platform-xclass-test-docker/src/test/it/org/xwiki/xclass/test/ui/AllIT.java A 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) * add XClassCacheVisibilityIT, a functional test that reproduces the race: one thread loads a document holding one object of each of 400 distinct XClasses while a second thread recreates a 401st XClass part-way through that load. The delay before recreating it is swept across the measured load window so that some round lands after the loading transaction took its snapshot and before it resolves that XClass. A round fails when the recreated XClass is reported as non-existing although flushing the cache brings it back, which proves the row was in the database all along. * assert separately that the store's connections run at READ COMMITTED, so that losing that setting fails here with a clear message instead of showing up as unrelated tests failing at random. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> (cherry picked from commit 5eadc17a50ec528f8e607cd69aa607a499323715) Commit: 1ef524f52825098e34cc7434e40ed8b43a62c271 https://github.com/xwiki/xwiki-platform/commit/1ef524f52825098e34cc7434e40ed... Author: Michael Hamann <[email protected]> Date: 2026-09-17 (Thu, 17 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]> (cherry picked from commit c28327d554a177476c939354a5f968f73e8c44aa) Compare: https://github.com/xwiki/xwiki-platform/compare/61c0fdc8df27...1ef524f52825 To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-platform/settings/notifications