Repository navigation
fix: stop scheduled jobs after switching to multi-user mode - #6656
Merged
timothycarambat merged 2 commits intoOct 7, 2026
Merged
timothycarambat merged 2 commits into
timothycarambat merged 2 commits into
Conversation
Scheduled jobs created in single-user mode kept running after switching to multi-user mode, even though every /scheduled-jobs route returns 401 there, so they could no longer be viewed, paused, or deleted. Their cron timers stayed active and every restart registered them again. Boot now skips registering jobs in multi-user mode, and enqueueScheduledJob returns null and clears the job's timer instead of starting a run.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Scheduled jobs are single-user only, but switching an instance to multi-user mode left them running. Their cron timers stayed registered,
enqueueScheduledJobstill started runs, and every restart registered them again, while every/scheduled-jobsroute answered 401, so the admin could no longer see or stop them.BackgroundServicenow checksSystemSettings.isMultiUserMode()in two places, the same way the Telegram bot stops itself in multi-user mode.#bootScheduledJobsregisters nothing, andenqueueScheduledJobreturnsnulland removes the job's timer instead of starting a run. The second check is what stops timers registered before the switch. The first keeps a multi-user boot from registering timers and loggingRegistered N scheduled job(s). The job rows are left as they are, so a later multi-user version of the feature still has them.A worker that is still running at the moment of the switch is ended the next time that job's timer fires, and its run is marked killed.
The trigger route already treats a
nullrun asskipped, the same as when a run is already in flight, and the cron callback ignores the return value.I ran the real background worker against a local stub LLM, with the job created through
POST /scheduled-jobs/newand the switch made throughPOST /system/enable-multi-user:Adding only the boot check is not enough, since the timer that is already registered keeps firing until the next restart. The new test in
server/__tests__/utils/BackgroundWorkers/index.test.jschecks thatenqueueScheduledJobstarts no run and drops the timer in multi-user mode, and fails on master. The server suite passes, 66 suites and 1419 tests. Prettier passes on both files, and eslint onserver/utils/BackgroundWorkers/index.js(the server config ignores__tests__).Closes #6655