Skip to content

fix: stop scheduled jobs after switching to multi-user mode - #6656

Merged
timothycarambat merged 2 commits into
Mintplex-Labs:masterfrom
marmar9615-cloud:fix/scheduled-jobs-multi-user
Oct 7, 2026
Merged

timothycarambat merged 2 commits into
Mintplex-Labs:masterfrom
marmar9615-cloud:fix/scheduled-jobs-multi-user

Conversation

@marmar9615-cloud

Copy link
Copy Markdown
Contributor

Scheduled jobs are single-user only, but switching an instance to multi-user mode left them running. Their cron timers stayed registered, enqueueScheduledJob still started runs, and every restart registered them again, while every /scheduled-jobs route answered 401, so the admin could no longer see or stop them.

BackgroundService now checks SystemSettings.isMultiUserMode() in two places, the same way the Telegram bot stops itself in multi-user mode. #bootScheduledJobs registers nothing, and enqueueScheduledJob returns null and 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 logging Registered 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 null run as skipped, 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/new and the switch made through POST /system/enable-multi-user:

after the switch                          master             this branch
cron timer registered before the switch   run completed      no run
enqueueScheduledJob                       returns a run      returns null, no run
boot() in multi-user mode                 1 timer            0 timers
single-user control                       job runs           job runs

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.js checks that enqueueScheduledJob starts 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 on server/utils/BackgroundWorkers/index.js (the server config ignores __tests__).

Closes #6655

marmar9615-cloud and others added 2 commits October 6, 2026 23:40
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.
@timothycarambat
timothycarambat merged commit 3c7e73b into Mintplex-Labs:master Oct 7, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG]: Scheduled jobs created in single-user mode keep running after switching to multi-user mode, and can no longer be viewed or stopped

2 participants