What causes "删除定时任务失败" in elunez/eladmin?

Inspect the stack trace after the '删除定时任务失败' log line to identify the SchedulerException cause.

elunez/eladmin · error · BadRequestException

删除定时任务失败

Error message

删除定时任务失败

What it means

QuartzManage.deleteJob does scheduler.pauseJob(jobKey) then scheduler.deleteJob(jobKey) inside a try/catch; any SchedulerException is logged and rethrown as BadRequestException '删除定时任务失败'. The calling service delete() is transactional, so the quartz_job DB row survives if the scheduler delete fails.

Source

Thrown at eladmin-system/src/main/java/me/zhengjie/modules/quartz/utils/QuartzManage.java:118

        } catch (Exception e){
            log.error("更新定时任务失败", e);
            throw new BadRequestException("更新定时任务失败");
        }

    }

    /**
     * 删除一个job
     * @param quartzJob /
     */
    public void deleteJob(QuartzJob quartzJob){
        try {
            JobKey jobKey = JobKey.jobKey(JOB_NAME + quartzJob.getId());
            scheduler.pauseJob(jobKey);
            scheduler.deleteJob(jobKey);
        } catch (Exception e){
            log.error("删除定时任务失败", e);
            throw new BadRequestException("删除定时任务失败");
        }
    }

    /**
     * 恢复一个job
     * @param quartzJob /
     */
    public void resumeJob(QuartzJob quartzJob){
        try {
            TriggerKey triggerKey = TriggerKey.triggerKey(JOB_NAME + quartzJob.getId());
            CronTrigger trigger = (CronTrigger) scheduler.getTrigger(triggerKey);
            // 如果不存在则创建一个定时任务
            if(trigger == null) {
                addJob(quartzJob);
            }
            JobKey jobKey = JobKey.jobKey(JOB_NAME + quartzJob.getId());
            scheduler.resumeJob(jobKey);
        } catch (Exception e){

View on GitHub (pinned to 55fbf70595)

Solutions

Inspect the stack trace after the '删除定时任务失败' log line to identify the SchedulerException cause.
Restore scheduler/database availability and retry the delete — it is idempotent from the UI.
If DB and scheduler state have diverged, manually reconcile (remove orphaned QRTZ_ rows or quartz_job rows) so both sides agree.

Defensive patterns

Strategy: try-catch

Validate before calling

// check the job exists in the scheduler before deleting
JobKey jk = JobKey.jobKey("JOB_NAME" + id);
if (scheduler.checkExists(jk)) { scheduler.pauseJob(jk); scheduler.deleteJob(jk); }
// then delete the DB row — avoids throwing on already-missing keys

Try / catch

try { quartzJobService.delete(ids); } catch (BadRequestException e) { if ("删除定时任务失败".equals(e.getMessage())) { log.error("scheduler delete failed", e); return fail("删除失败，详见服务端日志"); } throw e; }

Prevention

Use checkExists before pause/delete for idempotent deletes.
Keep QRTZ_ tables and quartz_job rows in sync during backups/restores.
Never delete scheduler rows manually via SQL without also cleaning quartz_job.

When it happens

Trigger: DELETE /api/quartz/jobs when the scheduler cannot process the delete: scheduler down/standby, JDBC job store unreachable, or job key in an inconsistent state. Deleting jobs whose scheduler entry is already gone can also surface errors depending on store implementation.

Common situations: Quartz JDBC store pointing at a database that is down; clustered scheduler node split; jobs deleted directly in QRTZ_ tables leaving orphaned keys; scheduler shut down during app shutdown race.

Related errors

AI-assisted analysis of elunez/eladmin@55fbf70595 (2026-08-14). Data as JSON: /api/errors/7b246f2f43c734ba. Report an issue: GitHub.