Skip to main content

Retry attribute for stacks

Feature RequestsStacks

There should be a stack setting that tells stacks to keep retrying for both proposed and tracked runs until a run is successful. Continuous retries are required to run at scale since stacks fail for reasons that just require a retry (provider download fail, worker pool error, dependent API blip, etc)

Workaround
Problem
Status: 🗑️ Archived2 comments

Log in to comment and vote

Comments2

  • Black Breeze

    •

    Sep 11, 2025

    Thanks for bringing this up.

    I see where you’re coming from but if implemented naively it’s a big bazooka and can easily get out of control, putting the stack in an endless crash loop.

    At the very least we could cap the number of retries? Plus, I guess one should not retry when there’s another job waiting that would otherwise acquire the stack lock (so a tracked run or a task).

    What’s your take on such an implementation Dan?

    • Silver Pretzel

      •

      Sep 11, 2025

      Setting limits makes sense:

      • self-hosted runners only

      • exponential backoff

      • maximum retry limit (1 hour)

      • stop retrying if there is a newer run

      • just started to use tasks so I don’t have a clear picture of what the expected behavior should be