Skip to content

[Fix] Fast automation Run now requests time out - #1659

Draft
roomote-roomote[bot] wants to merge 2 commits into
developfrom
fix/async-fast-automation-run-now
Draft

[Fix] Fast automation Run now requests time out#1659
roomote-roomote[bot] wants to merge 2 commits into
developfrom
fix/async-fast-automation-run-now

Conversation

@roomote-roomote

Copy link
Copy Markdown
Contributor

​Opened on behalf of @mrubens. Follow up by mentioning @roomote-roomote, in the web UI, or in Slack.

What changed

  • Accept manual Fast custom automation runs after atomically claiming and enqueueing them, returning an invocation ID without waiting for the full agent turn.
  • Add durable BullMQ execution with queued, running, succeeded, and failed status polling through both the API and the custom automation management tool.
  • Renew active claim leases, reject expired queued work, disable stalled-job replay, and fence cleanup so concurrent or recovered launches cannot duplicate external effects.
  • Stop describing timed-out non-idempotent platform API requests as safe to retry.

Why this change was made

Manual Fast runs previously held the API request open for the entire agent turn. Runs longer than the worker's two-minute platform API deadline completed successfully on the server but appeared to fail to the caller, making an unsafe duplicate retry likely.

Impact

Fast custom automation runs now acknowledge promptly and remain observable through a durable invocation status. Scheduled automation execution keeps its existing evaluator path, no database migration is required, and the existing settings experience continues to show that the automation is running.

@roomote-community

roomote-community Bot commented Aug 25, 2026

Copy link
Copy Markdown
Contributor

1 issue outstanding. See task

  • Queued cron Fast runs can execute after the automation is disabled (packages/sdk/src/server/automations/custom-automations.ts:721).

Reviewed e0be586

Comment on lines +721 to +723
if (
!automation ||
automation.executionMode !== 'fast' ||

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This validates the fence and execution mode but not the current enabled value. A Fast automation on a cron schedule can be disabled after run_now returns accepted but before this worker picks up the job; launchCustomAutomationRow bypasses its disabled guard for cron schedules during manual runs, so the queued invocation still sends the external Fast event. Reject and finalize the invocation when the freshly loaded automation is disabled, and add that queued-then-disabled regression case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants