Problem
Recurring automations can accumulate duplicate prompts indefinitely while their target thread is unable to run them. Each interval adds another queued prompt, and the task reports success even though its prompt has not started executing. Provider usage limits can leave this backlog growing while the thread still appears to be Working.
The bug continues to occur on the latest builds; it is not limited to a single version.
Reproduction
- Configure an enabled recurring automation that sends a prompt to an existing thread.
- Leave the target thread unable to process new work, for example while a turn is blocked by a provider usage limit.
- Allow several scheduled intervals to pass.
- Inspect the thread's queue and the automation's last-run status.
Each interval adds another copy of the prompt. The automation reports success after queue admission, although no execution has occurred.
Expected behavior
Recurring checks should retain one outstanding occurrence while the target is blocked, rather than build an unbounded backlog. Delivery should honor provider usage limits and held queues. The task should distinguish a queued prompt from one dispatched for execution.
Investigation
A controlled service-level reproduction confirmed that four scheduled intervals create four pending prompts when the target cannot process them. The scheduler releases its reservation after queue admission and advances to the next interval without checking whether work from the same task is still outstanding.
Queue promotion already checks recognized usage-limit blocks, but fresh queue-mode admission does not consistently apply those checks when no active run exists. A held queue can similarly be bypassed at admission. These paths should use consistent blocking rules.
The original stale Working state has not been traced to a confirmed root cause; preventing duplicate admission alone does not establish a fix for that state.
Suggested fix
Before admitting an automatic recurring occurrence, check whether that task already has outstanding work in its bound thread. Retain that occurrence and advance later intervals without adding duplicates. Apply usage-limit and held-queue checks consistently, and expose whether delivery was queued or dispatched. Preserve explicit Run now and webhook requests, existing queued messages, and the configured quota-recovery policy.
Problem
Recurring automations can accumulate duplicate prompts indefinitely while their target thread is unable to run them. Each interval adds another queued prompt, and the task reports success even though its prompt has not started executing. Provider usage limits can leave this backlog growing while the thread still appears to be Working.
The bug continues to occur on the latest builds; it is not limited to a single version.
Reproduction
Each interval adds another copy of the prompt. The automation reports success after queue admission, although no execution has occurred.
Expected behavior
Recurring checks should retain one outstanding occurrence while the target is blocked, rather than build an unbounded backlog. Delivery should honor provider usage limits and held queues. The task should distinguish a queued prompt from one dispatched for execution.
Investigation
A controlled service-level reproduction confirmed that four scheduled intervals create four pending prompts when the target cannot process them. The scheduler releases its reservation after queue admission and advances to the next interval without checking whether work from the same task is still outstanding.
Queue promotion already checks recognized usage-limit blocks, but fresh queue-mode admission does not consistently apply those checks when no active run exists. A held queue can similarly be bypassed at admission. These paths should use consistent blocking rules.
The original stale Working state has not been traced to a confirmed root cause; preventing duplicate admission alone does not establish a fix for that state.
Suggested fix
Before admitting an automatic recurring occurrence, check whether that task already has outstanding work in its bound thread. Retain that occurrence and advance later intervals without adding duplicates. Apply usage-limit and held-queue checks consistently, and expose whether delivery was queued or dispatched. Preserve explicit Run now and webhook requests, existing queued messages, and the configured quota-recovery policy.