Skip to content

Retry starting a run on memory and concurrent-runs limits #1071

Description

@B4nan

Starting a run can fail with a 400 whose type is actor-memory-limit-exceeded or concurrent-runs-limit-exceeded. Both mean "not now" rather than "never", but the client treats them like any other error, so every orchestrator has to write the same wait-and-retry loop around actor.start() / actor.call(). That loop is exactly what agent-written orchestrators get wrong.

Proposal

An opt-in option on ActorClient.start / call (and the task equivalents):

run = await client.actor('apify/web-scraper').call(run_input, wait_for_resources=True)

When set, the client retries the start on those two error types with a fixed cooldown (the orchestrator uses 10 s) until it succeeds or a timeout expires, then raises. Other errors raise immediately as today.

It stays in the client rather than the SDK because it needs nothing from the Actor runtime, only the error type and a sleep, and Actor.call in the SDK can forward the option.

Prior art

apify-orchestrator's scheduler: https://github.com/apify-professional-services/apify-orchestrator/blob/ef8b1c3feb1e08ea94ac40e1a1a6970b9c456a95/src/run-scheduler.ts and the error mapping in https://github.com/apify-professional-services/apify-orchestrator/blob/ef8b1c3feb1e08ea94ac40e1a1a6970b9c456a95/src/utils/apify-client.ts

✍️ Drafted by Claude Code

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request.t-toolingIssues with this label are in the ownership of the tooling team.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions