What causes "Resume command was not accepted within 5 seconds" in apache/druid?

Retry the resume call; transient pauses often clear once the consumer poll completes.

apache/druid · error · RuntimeException

Resume command was not accepted within 5 seconds

Error message

Resume command was not accepted within 5 seconds

What it means

In SeekableStreamIndexTaskRunner.pause(), after signaling shouldResume, the runner waits up to 5 seconds (awaitNanos loop) for the paused state to actually clear. If the task is still isPaused() after 5 seconds, it throws a RuntimeException because the resume command was not honored — usually the consumer's poll loop is stuck or the pause/resume protocol with the record supplier failed.

Source

Thrown at indexing-service/src/main/java/org/apache/druid/indexing/seekablestream/SeekableStreamIndexTaskRunner.java:2185

  {
    authorizationCheck(req);
    resume();
    return Response.status(Response.Status.OK).build();
  }


  @VisibleForTesting
  public void resume() throws InterruptedException
  {
    pauseLock.lockInterruptibly();
    try {
      pauseRequested = false;
      shouldResume.signalAll();

      long nanos = TimeUnit.SECONDS.toNanos(5);
      while (isPaused()) {
        if (nanos <= 0L) {
          throw new RuntimeException("Resume command was not accepted within 5 seconds");
        }
        nanos = shouldResume.awaitNanos(nanos);
      }
    }
    finally {
      pauseLock.unlock();
    }
  }


  @GET
  @Path("/time/start")
  @Produces(MediaType.APPLICATION_JSON)
  public DateTime getStartTime(@Context final HttpServletRequest req)
  {
    authorizationCheck(req);
    return startTime;
  }

View on GitHub (pinned to 9b90983fd2)

Solutions

Retry the resume call; transient pauses often clear once the consumer poll completes.
Check task logs for the poll loop or record supplier being stuck (network issues, broker down) and restore broker connectivity.
Restart/resume the task via supervisor so a fresh ingestion thread takes over the paused one.
If reproducible, tune poll/fetch timeouts (e.g. pollTimeout, fetch max wait) so resume can complete within the 5s window.

Example fix

// before: resume during a stuck task
curl -X POST 'http://middlemanager:8091/druid/worker/v1/task/<taskId>/resume'
// after: verify broker connectivity first, or reset via supervisor
curl -X POST 'http://overlord:8087/druid/indexer/v1/supervisor/my-supervisor/reset'

Defensive patterns

Strategy: retry

Try / catch

try { resume(taskId); } catch (RuntimeException e) { if (e.getMessage().contains("Resume command was not accepted")) { retryWithBackoff(() -> resume(taskId), 3); } else { throw e; } }

Prevention

Check broker/network health before pause/resume operations
Avoid pausing tasks during shutdown or maintenance windows
Keep consumer poll/fetch timeouts comfortably below 5s

When it happens

Trigger: Calling the task resume operation (or supervisor-triggered resume) while the task is paused, and within 5 seconds the ingestion loop does not observe/resume; typically because the task thread is blocked in a long Kafka/Kinesis poll, is hung on broker IO, or a previous pause signal raced with shutdown.

Common situations: Broker/network stall during pause; very long poll timeout or huge fetch causing slow resume; resume invoked concurrently with task shutdown/kill; deadlock between pauseLock and supplier threads under load.

Understand the failure class

Background: Request timed out: what client-side request timeouts mean across libraries (Request timed out, TIMED_OUT, APITimeoutError) — this error's family across 39 libraries.

Related errors

AI-assisted analysis of apache/druid@9b90983fd2 (2026-09-07). Data as JSON: /api/errors/e5cce2a6952b3d12. Report an issue: GitHub.