Workers poll at ~1s max regardless of `poll_interval` setting

[kazmiekr]

Overview

We wanted to slow down the poll interval for our workers to something like 5s to reduce the load on the servers, but noticed that they continued to poll at around a second. Using AI tools, it found an issue with the way the delays are being set. I had it write up an issue of what we're seeing. Let me know if there is a different way to handle this. Thanks!

Robot Description

Summary

Worker poll_interval values above ~1 second are effectively ignored. The exponential backoff logic in TaskRunner.run_once caps the exponent at 10, limiting the maximum delay between polls to 0.001 * 2^10 = 1.024 seconds regardless of the configured poll_interval.

Details

In task_runner.py, run_once calculates the polling delay with a capped exponent:

# Exponential backoff for empty polls (1ms, 2ms, 4ms, 8ms, up to poll_interval)
# Cap exponent at 10 to prevent overflow (2^10 = 1024ms = 1s)
capped_empty_polls = min(self._consecutive_empty_polls, 10)
min_poll_delay = min(0.001 * (2 ** capped_empty_polls), self.worker.get_polling_interval_in_seconds())

The comment says "up to poll_interval", but the backoff plateaus at ~1.024s because 0.001 * 2^10 = 1.024 is always less than any poll_interval above ~1 second. The min() call never selects poll_interval.

Impact

With workers configured at poll_interval=5000ms (5 seconds), we expected ~12 polls/min per worker but observed ~43 polls/min per worker, creating unnecessary load on our infrastructure.

Expected Behavior

When consecutive_empty_polls reaches steady state, the delay between polls should reach the full configured poll_interval value.

Suggested Fix

Either raise the exponent cap so the backoff can reach poll_interval, or call __wait_for_polling_interval() once the backoff has stabilized (e.g., when consecutive_empty_polls >= 10).

Environment

• conductor-python version: 1.3.2
• Python: 3.14