Skip to content

fix(schedules): remove the repeatable job that is actually registered - #5459

Open
Dev-next-gen wants to merge 1 commit into
Dokploy:canaryfrom
Dev-next-gen:fix/remove-job-live-pattern
Open

Dev-next-gen wants to merge 1 commit into
Dokploy:canaryfrom
Dev-next-gen:fix/remove-job-live-pattern

Conversation

@Dev-next-gen

@Dev-next-gen Dev-next-gen commented Sep 13, 2026

Copy link
Copy Markdown

What is this PR about?

While reviewing #5454 I was pointed at the schedules service, and the mismatch is there rather than in the routers. /remove-job passes the cronSchedule it receives straight to jobQueue.removeRepeatable, which rebuilds the BullMQ repeatable key from that value. The cron the callers send comes from the database row, and it can already have been replaced by an earlier update that never reached the queue, so the rebuilt key does not match the pattern the live repeatable was registered with. Nothing is removed, the endpoint answers result: false, and the job keeps firing. The same happens when only the timezone of a schedule changed.

/update-backup, a few lines above in the same file, already avoids this: it looks the job up with getJobRepeatable and removes it with job.pattern, ignoring the cron the caller sent. I moved that resolution into removeJob itself, so /remove-job gets it too and all four callers benefit at once: backup.remove, schedule.delete, volumeBackups.delete (and the disable branch of volumeBackups.update), and the server cleanup in settings.ts. None of them needed a change. The per-type block in /update-backup became redundant and is gone, which is where most of the deleted lines come from.

Removing a job that is not registered anymore still returns false rather than throwing, so the callers that ignore the result behave exactly as before.

I added apps/dokploy/__test__/schedules/remove-job-live-pattern.test.ts, which registers a repeatable, simulates the stored cron drifting, and calls removeJob with the new value. On canary the three drift cases fail (removeRepeatable returns false and the job survives); with this change the six tests pass. pnpm --filter=@dokploy/schedules typecheck and the dokploy tsc --noEmit are clean, and biome check reports nothing new on the touched files.

Checklist

Before submitting this PR, please make sure that:

  • You created a dedicated branch based on the canary branch.
  • You have read the suggestions in the CONTRIBUTING.md file https://github.com/Dokploy/dokploy/blob/canary/CONTRIBUTING.md#pull-request
  • You have tested this PR in your local instance. If you have not tested it yet, please do so before submitting. This helps avoid wasting maintainers' time reviewing code that has not been verified by you.

Issues related (if applicable)

Follow-up to the review discussion on #5454: #5454 (comment)

AI tools used

RetriggerConfidence Score: 5/5

This PR appears safe to merge.

Summary

  • Looks up each repeatable job by its stable name before removing it.
  • Passes the live job pattern and timezone to BullMQ instead of caller-provided values.
  • Reuses the fix across update, remove, delete, disable, and server cleanup callers.
  • Adds focused tests for drifted schedules and missing jobs.

Reviews (1) · Last reviewed commit: "fix(schedules): remove the repeatable jo..."

/remove-job passed the caller's cronSchedule straight to
removeRepeatable, so the BullMQ key was rebuilt from the cron stored in
the database. When that value has drifted from the pattern the live
repeatable was registered with, the key does not match, nothing is
removed and the job keeps firing. /update-backup already avoided this by
resolving the job with getJobRepeatable and removing it with
job.pattern.

Do that resolution inside removeJob, so every caller gets it: the delete
paths of backups, schedules and volume backups, and the server cleanup.
The per-type block in /update-backup becomes redundant and is dropped.

Removing a job that is already gone still returns false instead of
throwing, so the callers that ignore the result keep working as before.
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.

1 participant