What causes "Long Poll Timeout value cannot be more than 5 seconds" in conductor-oss/conductor?

Set the poll timeout to 5000 milliseconds (5 seconds) or less in the worker/poll request.

conductor-oss/conductor · error · IllegalArgumentException

Long Poll Timeout value cannot be more than 5 seconds

Error message

Long Poll Timeout value cannot be more than 5 seconds

What it means

Thrown by ExecutionService.poll when the long-poll timeout parameter exceeds MAX_POLL_TIMEOUT_MS (5000 milliseconds / 5 seconds). Conductor caps long-poll duration at 5 seconds to prevent workers from holding connections open too long. This is an IllegalArgumentException returned as a 400 Bad Request from the REST/gRPC API.

Source

Thrown at core/src/main/java/com/netflix/conductor/service/ExecutionService.java:114

    }

    public Task poll(String taskType, String workerId, String domain) {

        List<Task> tasks = poll(taskType, workerId, domain, 1, 100);
        if (tasks.isEmpty()) {
            return null;
        }
        return tasks.get(0);
    }

    public List<Task> poll(String taskType, String workerId, int count, int timeoutInMilliSecond) {
        return poll(taskType, workerId, null, count, timeoutInMilliSecond);
    }

    public List<Task> poll(
            String taskType, String workerId, String domain, int count, int timeoutInMilliSecond) {
        if (timeoutInMilliSecond > MAX_POLL_TIMEOUT_MS) {
            throw new IllegalArgumentException(
                    "Long Poll Timeout value cannot be more than 5 seconds");
        }
        String queueName = QueueUtils.getQueueName(taskType, domain, null, null);

        List<String> taskIds = new LinkedList<>();
        List<Task> tasks = new LinkedList<>();
        try {
            taskIds = queueDAO.pop(queueName, count, timeoutInMilliSecond);
        } catch (Exception e) {
            LOGGER.error(
                    "Error polling for task: {} from worker: {} in domain: {}, count: {}",
                    taskType,
                    workerId,
                    domain,
                    count,
                    e);
            Monitors.error(this.getClass().getCanonicalName(), "taskPoll");
            Monitors.recordTaskPollError(taskType, domain, e.getClass().getSimpleName());

View on GitHub (pinned to cf7c3e4a8a)

Solutions

Set the poll timeout to 5000 milliseconds (5 seconds) or less in the worker/poll request.
If longer effective wait is needed, implement client-side retry loop: poll with 5s timeout, and if no task, poll again.
Update the worker SDK configuration to use a timeout within the 0–5000ms range.

Example fix

// before — timeout too high
GET /api/tasks/poll/batch/my_task?count=1&timeout=30000
// 400: Long Poll Timeout value cannot be more than 5 seconds

// after
GET /api/tasks/poll/batch/my_task?count=1&timeout=5000

Defensive patterns

Strategy: validation

Validate before calling

// Clamp poll timeout to the server max before sending the request
private static final int MAX_POLL_TIMEOUT_MS = 5000;

int safeTimeout = Math.min(requestedTimeoutMs, MAX_POLL_TIMEOUT_MS);
List<Task> tasks = executionService.poll(taskType, workerId, count, safeTimeout);

Type guard

public static boolean isValidPollTimeout(int timeoutMs) {
    return timeoutMs >= 0 && timeoutMs <= 5000;
}

Prevention

Always cap poll timeout at 5000ms in worker SDK configuration.
For longer effective wait, implement a client-side poll loop with 5s individual timeouts.
Document the 5-second cap prominently in worker SDK docs.

When it happens

Trigger: Calling the task poll API (GET /api/tasks/poll/{taskType} or /api/tasks/poll/batch/{taskType}) with a timeoutInMilliSecond query parameter greater than 5000. Also via the gRPC Poll endpoint with a timeout exceeding the cap. The constant MAX_POLL_TIMEOUT_MS is hardcoded at 5000 in both the REST and gRPC services.

Common situations: A worker SDK or custom client passes a large timeout value (e.g. 30000ms) expecting long-poll behavior similar to SQS. Copy-pasting a poll configuration from another system that allows 20-30 second long polls. Client-side default that was not adjusted to Conductor's 5-second cap.

Understand the failure class

Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

AI-assisted analysis of conductor-oss/conductor@cf7c3e4a8a (2026-08-14). Data as JSON: /api/errors/134acd463a390cde. Report an issue: GitHub.