Branch: refs/heads/XWIKI-15952 Home: https://github.com/xwiki/xwiki-platform Commit: a648f55d7a5d6cb5298c5da8cdaa7fa0934b8f70 https://github.com/xwiki/xwiki-platform/commit/a648f55d7a5d6cb5298c5da8cdaa7... Author: Vincent Massol <vincent@massol.net> Date: 2026-08-26 (Wed, 26 Aug 2026) Changed paths: M xwiki-platform-core/xwiki-platform-scheduler/xwiki-platform-scheduler-api/src/main/java/com/xpn/xwiki/plugin/scheduler/SchedulerPlugin.java M xwiki-platform-core/xwiki-platform-scheduler/xwiki-platform-scheduler-test/xwiki-platform-scheduler-test-docker/src/test/it/org/xwiki/scheduler/test/ui/SchedulerIT.java A xwiki-platform-core/xwiki-platform-scheduler/xwiki-platform-scheduler-test/xwiki-platform-scheduler-test-pageobjects/src/main/java/org/xwiki/scheduler/test/po/SchedulerJobOutputPage.java Log Message: ----------- XWIKI-15952: Update Scheduled Job With Job Re-Definition * Re-register a job that is already known to the scheduler when its definition changes, so that saving a job document is enough for the new definition to be used. The scheduler is given the job xobject when the job is registered and reads the script from that instance, so until now an edited script or cron expression kept being ignored until the job was unscheduled and scheduled again, or until XWiki was restarted. The job silently kept running its previous code, which is worse than failing. * Reuse reloadJob(), which already re-creates a job and puts it back in the state it was in. * Ignore a modification that only changes the status field, since the scheduler saves that field itself whenever it registers, pauses or unregisters a job, which would otherwise reload the job again in the middle of its own save. * Leave alone a job that the scheduler doesn't know about, so that saving an unscheduled job doesn't add a dormant job to the scheduler. Such a job is registered with its new definition when it gets scheduled. * Add an integration test scheduling a job that writes a known content, then modifying its script and triggering it again. It fails on the previous behaviour, on the second content only, which is the part the fix addresses. * Add a SchedulerJobOutputPage page object exposing the wait for the content a job writes, so that the test doesn't reach for the web driver itself. A job is executed asynchronously from the action that triggers it, so waiting for its content means reloading the page, which no existing page object does: ViewPage#waitUntilContent() deliberately doesn't reload, since reloading a page would start over an asynchronous process that the page itself triggered. * Create the page a job writes to before scheduling the job, so that waiting for a content is waiting for it to replace a known one. Locating the content of a page that doesn't exist yet fails with a wait of its own, which consumes the whole timeout and leaves a failure reporting no content at all rather than the content it found. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-platform/settings/notifications