September 2026 - notifications

[xwiki-contrib/ai-llm] f3aae6: [maven-release-plugin] prepare for next developmen...
by XWiki Notifications 18 Sep '26

18 Sep '26

Branch: refs/heads/main Home: https://github.com/xwiki-contrib/ai-llm Commit: f3aae6382bb0e587c73ede4b2dc34a72e279420a https://github.com/xwiki-contrib/ai-llm/commit/f3aae6382bb0e587c73ede4b2dc3… Author: Paul Pantiru <paul.pantiru(a)xwiki.com> Date: 2026-09-18 (Fri, 18 Sep 2026) Changed paths: M application-ai-llm-authentication/application-ai-llm-authentication-api/pom.xml M application-ai-llm-authentication/application-ai-llm-authentication-ui/pom.xml M application-ai-llm-authentication/pom.xml M application-ai-llm-chat/application-ai-llm-chat-webjar/pom.xml M application-ai-llm-chat/pom.xml M application-ai-llm-flavor/pom.xml M application-ai-llm-index/application-ai-llm-index-api/pom.xml M application-ai-llm-index/application-ai-llm-index-ui/pom.xml M application-ai-llm-index/pom.xml M application-ai-llm-mcp/application-ai-llm-mcp-api/pom.xml M application-ai-llm-mcp/application-ai-llm-mcp-server/pom.xml M application-ai-llm-mcp/application-ai-llm-mcp-ui/pom.xml M application-ai-llm-mcp/pom.xml M application-ai-llm-models/application-ai-llm-models-api/pom.xml M application-ai-llm-models/application-ai-llm-models-internal/pom.xml M application-ai-llm-models/application-ai-llm-models-ui/pom.xml M application-ai-llm-models/pom.xml M application-ai-llm-xip/pom.xml M pom.xml Log Message: ----------- [maven-release-plugin] prepare for next development iteration To unsubscribe from these emails, change your notification settings at https://github.com/xwiki-contrib/ai-llm/settings/notifications

1 0

[xwiki/xwiki-platform] f89a35: [Misc] Speedup NotificationsIT by REST calls
by XWiki Notifications 18 Sep '26

18 Sep '26

Branch: refs/heads/notifications-it-rest-fixture Home: https://github.com/xwiki/xwiki-platform Commit: f89a35e97f1fcb394d6c7ad45f2eea4b731af622 https://github.com/xwiki/xwiki-platform/commit/f89a35e97f1fcb394d6c7ad45f2e… Author: Manuel Leduc <manuel.leduc(a)xwiki.com> Date: 2026-09-18 (Fri, 18 Sep 2026) Changed paths: M xwiki-platform-core/xwiki-platform-notifications/xwiki-platform-notifications-test/xwiki-platform-notifications-test-docker/src/test/it/org/xwiki/platform/notifications/test/ui/NotificationsIT.java Log Message: ----------- [Misc] Speedup NotificationsIT by REST calls * Locate the comment and the page-update notifications of compositeNotifications by their type instead of their position: both events share the same instant, so the tray returns them in either order, just as the RSS feed already did. * Assert the update group holds PAGE_UPDATE_COUNT events: adding the comment over REST creates the comment object without updating the page content, so it does not add an event to that group. * Restore the browser-driven version of simpleNotifications: creating its pages over REST makes them simultaneous, and the notification system then groups them, so the per-page counts and the positions the test asserts on are no longer stable. To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-platform/settings/notifications

1 0

[xwiki-contrib/ai-llm]
by XWiki Notifications 18 Sep '26

18 Sep '26

Branch: refs/tags/application-ai-llm-0.10 Home: https://github.com/xwiki-contrib/ai-llm To unsubscribe from these emails, change your notification settings at https://github.com/xwiki-contrib/ai-llm/settings/notifications

1 0

[xwiki-contrib/ai-llm] 514d4a: [maven-release-plugin] prepare release application...
by XWiki Notifications 18 Sep '26

18 Sep '26

Branch: refs/heads/main Home: https://github.com/xwiki-contrib/ai-llm Commit: 514d4a40462198148d0a145e3f0410852187e512 https://github.com/xwiki-contrib/ai-llm/commit/514d4a40462198148d0a145e3f04… Author: Paul Pantiru <paul.pantiru(a)xwiki.com> Date: 2026-09-18 (Fri, 18 Sep 2026) Changed paths: M application-ai-llm-authentication/application-ai-llm-authentication-api/pom.xml M application-ai-llm-authentication/application-ai-llm-authentication-ui/pom.xml M application-ai-llm-authentication/pom.xml M application-ai-llm-chat/application-ai-llm-chat-webjar/pom.xml M application-ai-llm-chat/pom.xml M application-ai-llm-flavor/pom.xml M application-ai-llm-index/application-ai-llm-index-api/pom.xml M application-ai-llm-index/application-ai-llm-index-ui/pom.xml M application-ai-llm-index/pom.xml M application-ai-llm-mcp/application-ai-llm-mcp-api/pom.xml M application-ai-llm-mcp/application-ai-llm-mcp-server/pom.xml M application-ai-llm-mcp/application-ai-llm-mcp-ui/pom.xml M application-ai-llm-mcp/pom.xml M application-ai-llm-models/application-ai-llm-models-api/pom.xml M application-ai-llm-models/application-ai-llm-models-internal/pom.xml M application-ai-llm-models/application-ai-llm-models-ui/pom.xml M application-ai-llm-models/pom.xml M application-ai-llm-xip/pom.xml M pom.xml Log Message: ----------- [maven-release-plugin] prepare release application-ai-llm-0.10 To unsubscribe from these emails, change your notification settings at https://github.com/xwiki-contrib/ai-llm/settings/notifications

1 0

[[email protected]][Issue] Updates for XCOMMONS-2092: Possible race condition in ReadWriteSemaphore
by XWiki Notifications 18 Sep '26

18 Sep '26

1 0

[xwiki/xwiki-dev-llm] 75ac3f: [Misc] Cover two traps that make a red CI test loo...
by XWiki Notifications 18 Sep '26

18 Sep '26

Branch: refs/heads/okf-env-tests-snapshot Home: https://github.com/xwiki/xwiki-dev-llm Commit: 75ac3fd65715a11cf49a08d0e47acd81ef30c0cb https://github.com/xwiki/xwiki-dev-llm/commit/75ac3fd65715a11cf49a08d0e47ac… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-18 (Fri, 18 Sep 2026) Changed paths: M xwiki/okf/servers/jenkins.md M xwiki/okf/testing/strategy.md Log Message: ----------- [Misc] Cover two traps that make a red CI test look like a defect * Environment Tests builds only the test modules it is given and takes every other artifact from the last snapshot deployed to Nexus, so a commit adding a test together with the code that test needs is transiently red there; record the line-number check against the commit's parent that tells that apart from a real failure. * A programming-rights-checker pattern anchored on a test class's own name must allow a prefix, since the page is named after the running class and gains a "Nested" prefix inside an AllIT, which is how CI runs it. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications

1 0

[xwiki/xwiki-commons]
by XWiki Notifications 18 Sep '26

18 Sep '26

Branch: refs/heads/XCOMMONS-2092 Home: https://github.com/xwiki/xwiki-commons To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-commons/settings/notifications

1 0

[xwiki/xwiki-commons] 697430: XCOMMONS-2092: Possible race condition in ReadWrit...
by XWiki Notifications 18 Sep '26

18 Sep '26

Branch: refs/heads/master Home: https://github.com/xwiki/xwiki-commons Commit: 6974307afc785333fdb230f4ca6d0e882e892463 https://github.com/xwiki/xwiki-commons/commit/6974307afc785333fdb230f4ca6d0… Author: Simon Urli <simon.urli(a)xwiki.com> Date: 2026-09-18 (Fri, 18 Sep 2026) Changed paths: M xwiki-commons-core/xwiki-commons-job/xwiki-commons-job-default/src/main/java/org/xwiki/job/internal/ReadWriteSemaphore.java M xwiki-commons-core/xwiki-commons-job/xwiki-commons-job-default/src/test/java/org/xwiki/job/internal/DefaultJobExecutorTest.java A xwiki-commons-core/xwiki-commons-job/xwiki-commons-job-default/src/test/java/org/xwiki/job/internal/ReadWriteSemaphoreTest.java Log Message: ----------- XCOMMONS-2092: Possible race condition in ReadWriteSemaphore (#1963) * ReadWriteSemaphore#lockWrite/unlockWrite/lockRead/unlockRead mutated writeCounter/readCounter with incrementAndGet()/decrementAndGet() and then made the permits decision from a separate, later get() call, letting concurrent callers race and compute the wrong number of permits to acquire or release; a stress test hammering the same parent/child pool shape as the flaky test (pool sizes 1 and 2) reliably deadlocked within a couple hundred operations because of this * Guard the counter mutation and the resulting permit-count decision with an internal lock so each call makes its decision atomically; the lock is released before the (possibly blocking) semaphore acquire/release, so a thread waiting for a permit never holds a lock another thread needs in order to release one * Verified with a stress test reproducing the deadlock against the original code and confirming it cannot reproduce against the fix (5 runs x 3M operations each, no failure), and 500 repetitions of every test in DefaultJobExecutorTest (1500 runs total, 0 failures) * Replace the Semaphore-and-permit-count scheme with a plain monitor (synchronized/wait/notifyAll) that checks readCounter/writeCounter/activeWriters directly: a writer can proceed once activeWriters + readCounter is below the pool size, a reader once no writer is announced or active. This removes the whole class of "permits taken and given back don't match" bugs (the exact one the previous commit's non-atomicity fix targeted, and others found in the course of validating it) by construction: there is nothing to keep resynchronized with reality any more. * Serve waiting writers in the order they called lockWrite(), via an explicit ticket: plain wait()/notifyAll() does not by itself guarantee that a slot freed up for the earliest-still-waiting writer cannot be taken by a later one instead, which matchingGroupPathAreBlockedPoolMultiSizeChildrenFirst caught happening about half the time. * Restore (as a targeted, commented wait, not a blanket workaround) the synchronization the first commit on this issue had removed between submitting a writer and submitting a reader that must queue behind it in matchingGroupPathAreBlockedPoolMultiSizeParentFirst: nothing in ReadWriteSemaphore itself can guarantee an earlier-submitted writer's worker thread reaches its own lockWrite() call before a later-submitted reader's thread reaches lockRead(), since that is a property of when each gets dispatched by the surrounding thread pool, not of the semaphore's internal bookkeeping. * Add ReadWriteSemaphoreTest with a concurrent stress test reproducing, within a few hundred operations, the original non-atomic-counter deadlock this whole change started from. Verified with the concurrency stress test (reliably deadlocks the pre-atomicity-fix code, passes against this one), and with 5000/5000, 5000/5000 and 1500/1500 repeated runs of the three DefaultJobExecutorTest methods (matchingGroupPathAreBlocked, ...ParentFirst, ...ChildrenFirst), each in its own fresh JVM, 0 failures. * java:S2273 on ReadWriteSemaphore#waitUninterruptibly(): both call sites already hold the monitor's lock before calling this private method, but Sonar cannot verify that across the method boundary. Suppressed with a comment explaining why. * java:S2925 on the Thread.sleep() in matchingGroupPathAreBlockedPoolMultiSizeParentFirst: there is no observable state change to poll on instead, as already explained by the comment above the call (and as already accepted, unsuppressed, for the identical pattern in matchingGroupPathAreBlockedPoolMultiSizeChildrenFirst). Suppressed at the test method. * java:S1134 on the same test: dropped the redundant "FIXME:" comment line, since the paragraph above it already explains the constraint in full - it was never an outstanding task, just copied wording from the pre-existing pattern in the sibling test method. * Replace the java:S5961 suppression added by the previous commit with an actual cleanup of DefaultJobExecutorTest. SonarJava counts assertions reached through private helpers, so 10 of the 28 it reported on matchingGroupPathAreBlockedPoolMultiSizeParentFirst were the fail() inside waitJobState(), and 12 of the 18 remaining direct assertions only restated the state the waitJobXxx() call right above them had already established. * Drop those pure restatements in the three matchingGroupPath* tests, keeping every assertNull() (a job that must not have started yet is the property under test) and every "still in that state" re-check no preceding wait covers. Assertion counts as SonarJava computes them: 28 -> 21, 29 -> 21 and 18 -> 12. Splitting the methods instead was rejected: each one is a single choreography over live threads whose assertions are checkpoints on one timeline, so every split test would have to replay all the steps before its own. * Extract the repeated GroupedJobInitializer stubbing into mockPool(poolSize, path...) and mockAllPools(poolSize), so each test opens with the pool sizes its scenario comment describes. * Remove a duplicated assertion on job1 at the end of matchingGroupPathAreBlocked. It was meant to be on job12, whose final state the assertion above it already covers. * Fix two comments mangled by a search and replace ("taken into ABcount", "they are ABtually after"). * waitJobState() reported its timeout through fail(), and assertion-aware analysis resolves helper methods transitively, so every waitJobWaiting()/waitJobFinished() call counted as an assertion of the calling test. Each checkpoint of these tests was therefore counted twice: once for the barrier that drives the choreography to its next step, and once for the assertion that states what is expected there. That is what took matchingGroupPathAreBlockedPoolMultiSizeParentFirst to 28 for a method stating 18 expectations. * Raise that timeout by throwing instead. Assertions.fail() is itself a throw of an AssertionError subclass, so behaviour and Surefire reporting are unchanged, and the count now equals the number of expectations each test states: 28 -> 18, 29 -> 17 and 18 -> 12. The java:S5961 suppression added by the previous commit is dropped. * The same helper resolution applies to "tests should include assertions", where the effect is worse: a test whose only assertion-like call is a wait would have looked like it verifies something. It no longer does. * Restore the interrupt flag and keep the InterruptedException as the cause, instead of swallowing both. * Extract the repeated GroupedJobInitializer stubbing into mockPool(poolSize, path...) and mockAllPools(poolSize), so each test opens with the pool sizes its scenario comment describes. * Fix the last assertion of matchingGroupPathAreBlocked, which was on job1 twice instead of job12 and job1. * Fix two comments mangled by a search and replace ("taken into ABcount", "they are ABtually after"). --------- Co-authored-by: Claude Sonnet 5 <noreply(a)anthropic.com> Co-authored-by: Vincent Massol <vincent(a)massol.net> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-commons/settings/notifications

1 0

[xwiki/xwiki-platform] 9dd4f1: XWIKI-6161: Reset action does not work anymore (#6...
by XWiki Notifications 18 Sep '26

18 Sep '26

Branch: refs/heads/master Home: https://github.com/xwiki/xwiki-platform Commit: 9dd4f149c87abd4b5104e40cd5b832ee602c7359 https://github.com/xwiki/xwiki-platform/commit/9dd4f149c87abd4b5104e40cd5b8… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-18 (Fri, 18 Sep 2026) Changed paths: M xwiki-platform-core/xwiki-platform-flamingo/xwiki-platform-flamingo-skin/xwiki-platform-flamingo-skin-test/xwiki-platform-flamingo-skin-test-docker/src/test/it/org/xwiki/flamingo/test/docker/VersionIT.java Log Message: ----------- XWIKI-6161: Reset action does not work anymore (#6449) * Reset the history of a document that is no longer in the document cache, so that the reset action has to load the document and its history in the very transaction that resets them, which is the case that was broken. The test was passing against the code from before the fix, since a document that was just created is still cached with a history loaded by an earlier transaction and the reset then takes a path that works either way. Co-authored-by: Claude Opus 5 (1M context) <noreply(a)anthropic.com> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-platform/settings/notifications

1 0

[xwiki/xwiki-platform]
by XWiki Notifications 18 Sep '26

18 Sep '26

Branch: refs/heads/XWIKI-6161-2 Home: https://github.com/xwiki/xwiki-platform To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-platform/settings/notifications

1 0