Hi. I am using the LocalExecutor for a flow that has mapped tasks. The idea is for it to run tasks one at a time. However, when a mapped task fails, it blocks until that task is retried and it ultimately succeeds or fails. Is it possible to configure another executor so that tasks are run one at a time but the flow does not get stuck waiting on failed tasks that will be retried? Thanks

You can turn off retries if you don’t want them or lower the amount?

I'd like the retries but don't want them to block other mapped tasks that could be running.

But if it’s sequential you only have one mapped task at a time right?

A little more background. Each of these API calls costs a variable number of credits but we don't know ahead of time so we need to try them all. If there are enough credits, the calls will go through but if there are not enough credits for one call, we'd like to attempt the next calls which may be cheaper. By adding retry logic (and some notifications) we give the team a chance to go and add more credits to the account so those missing calls will eventually succeed. So there is no need for the calls to happen sequentially necessarily but we should not make too many calls at once. Is there a way to set things up where if a task is waiting to be retried, another task can be processed? I have not used tags for task concurrency limiting. Would this help if I set the limit to 1? In other words, would a task that is in retry state occupy a concurrency "slot"?

@Pedro Machado The way I understand concurrency limits for tasks is that it determines how many tasks with a specific tag can be in a Running state simultaneously. A task which is in Failed or Retrying state will therefore not count to this limit. But the best way to verify if it’s working as intended for your use case is when you try it in your flow. But note that if multiple tasks should all run with a limit of 1, you would need to set a corresponding tag on each of those tasks.

Great! I'll test it out. Thanks