polling configuration section controls the orchestrator’s tick frequency and reconciliation behavior.
Configuration
WORKFLOW.md
Fields
Poll interval in milliseconds (30 seconds default).The orchestrator runs a full tick on this cadence:
- Reconcile running issues (state refresh, stall detection)
- Validate configuration (dispatch preflight checks)
- Fetch candidate issues from tracker
- Dispatch eligible issues while slots remain
- Notify observability consumers (dashboard, logs)
5000= 5 seconds (high frequency)30000= 30 seconds (default)60000= 1 minute (conservative)300000= 5 minutes (low frequency)
Poll Tick Lifecycle
Each tick follows this sequence:Reconciliation (Every Tick)
Before dispatch, the orchestrator reconciles running issues:Stall Detection
For each running issue:State Refresh
- Fetch current tracker states for all running issue IDs
- For each running issue:
- Terminal state → Terminate worker, clean workspace
- Still active → Update in-memory snapshot
- Neither active nor terminal → Terminate worker (no cleanup)
- If state refresh fails → Keep workers running, retry next tick
Dispatch Preflight Validation
Before fetching candidates, the orchestrator validates:tracker.kindis present and supportedtracker.api_keyis present after environment resolutiontracker.project_slugis present (when required)codex.commandis present and non-empty
- Skip dispatch for this tick
- Reconciliation still runs
- Log operator-visible error
- Keep last known good config
Candidate Selection
The orchestrator fetches issues from the tracker and filters by:- Required fields: Has
id,identifier,title,state - Active state: State is in
tracker.active_states - Not terminal: State is not in
tracker.terminal_states - Not claimed: Not in
runningorretry_attemptsmaps - Concurrency slots: Global and per-state limits allow dispatch
- Blocker rule (Todo only): No non-terminal blockers
Dispatch Sorting
Candidates are sorted by:- Priority (ascending):
1>2>3>4>null - Created at (oldest first)
- Identifier (lexicographic tie-breaker)
Polling Frequency Considerations
High Frequency (5-10 seconds)
Pros:- Fast reaction to new issues
- Quick reconciliation of state changes
- Lower latency for continuation retries
- More API requests to tracker
- Higher CPU usage for reconciliation
- Potential rate limiting from tracker API
Medium Frequency (30-60 seconds)
Pros:- Balanced API usage
- Reasonable reaction time
- Default setting for most workloads
- Moderate delay before new issues are picked up
Low Frequency (5+ minutes)
Pros:- Minimal API usage
- Low overhead
- Suitable for batch workflows
- High latency for new issue pickup
- Slower reconciliation of terminal states
- Longer delays for retry/continuation
Configuration Reloading
Polling interval changes are applied dynamically:- Read from
WORKFLOW.mdon every tick - Applied to next tick scheduling
- No restart required
- Current tick completes with original interval
Startup Behavior
On service startup:- Initialize state with default
poll_interval_ms - Run terminal cleanup: Query tracker for terminal issues and remove workspaces
- Schedule immediate tick (
delay_ms: 0) - Start polling loop
Observability
The orchestrator exposes polling state to observability consumers:next_poll_due_at_ms: Monotonic timestamp for next tickpoll_check_in_progress: Boolean flag for active tick- Dashboard updates after each tick (
notify_dashboard())
Examples
Fast Iteration
- Development environments
- High-priority issue queues
- Real-time workflows
Production Default
- Standard production deployments
- Balanced API usage
- Most team workflows
Batch Processing
- Low-frequency batch jobs
- API rate limit avoidance
- Background maintenance tasks
Conservative (API Rate Limiting)
- Strict API quotas
- Low-traffic projects
- Long-running agent sessions