quarkusio/quarkus · error · RuntimeException

Unable to resume job

Error message

Unable to resume job

What it means

Quarkus wraps a Quartz SchedulerException thrown while resuming a single paused job via Scheduler.resume(identity) into this RuntimeException. It calls scheduler.resumeJob(new JobKey(identity, ...)) on the underlying Quartz scheduler; JobStore failures surface here with the SchedulerException as cause.

Source

Thrown at extensions/quartz/runtime/src/main/java/io/quarkus/quartz/runtime/QuartzSchedulerImpl.java:447

    @Override
    public void resume(String identity) {
        if (!isStarted()) {
            throw notStarted();
        }
        Objects.requireNonNull(identity, "Cannot resume - identity is null");
        if (identity.isEmpty()) {
            LOGGER.warn("Cannot resume - identity is empty");
            return;
        }
        try {
            String parsedIdentity = SchedulerUtils.lookUpPropertyValue(identity);
            QuartzTrigger trigger = scheduledTasks.get(parsedIdentity);
            if (trigger != null) {
                scheduler.resumeJob(new JobKey(SchedulerUtils.lookUpPropertyValue(parsedIdentity), Scheduler.class.getName()));
                events.fireScheduledJobResumed(new ScheduledJobResumed(trigger));
            }
        } catch (SchedulerException e) {
            throw new RuntimeException("Unable to resume job", e);
        }
    }

    @Override
    public boolean isRunning() {
        if (!isStarted()) {
            return false;
        } else {
            try {
                return !scheduler.isInStandbyMode();
            } catch (SchedulerException e) {
                throw new IllegalStateException("Could not evaluate standby mode", e);
            }
        }
    }

    @Override
    public List<Trigger> getScheduledJobs() {

View on GitHub (pinned to e1c734241f)

Solutions

  1. Inspect the cause SchedulerException for the underlying store error
  2. Verify datasource connectivity when using the jdbc store
  3. Check for stale rows/locks in the Quartz cluster tables (qrtz_locks, qrtz_scheduler_state)
  4. Retry the resume after the store is healthy

Example fix

// before
scheduler.resume("myJob");
// after
try {
    scheduler.resume("myJob");
} catch (RuntimeException e) {
    LOGGER.errorf(e.getCause(), "resume failed for job");
}
Defensive patterns

Strategy: try-catch

Validate before calling

Trigger t = scheduler.getScheduledJob(identity);
if (t == null) { LOGGER.warnf("Job %s not registered; resume skipped", identity); }

Try / catch

try {
    scheduler.resume(identity);
} catch (RuntimeException e) {
    LOGGER.errorf(e.getCause(), "Cannot resume job %s", identity);
}

Prevention

When it happens

Trigger: Calling Scheduler.resume(identity) for a known paused job when the underlying resumeJob call fails — JDBC JobStore DB error, cluster lock failure, or store state inconsistency for the job's triggers.

Common situations: JDBC store database outage or connection-pool exhaustion; job paused while the app ran against one DB then resumed against another; clustered mode with a stale scheduler entry holding locks.

Related errors

AI-assisted analysis of quarkusio/quarkus@e1c734241f (2026-09-05). Data as JSON: /api/errors/e649fa42ba809ce5. Report an issue: GitHub.