Fernando Müller
07/16/2025, 8:27 PMmatch_latest_revision_in_family job variable to True in an attempt to avoid the creation of new tasks definitions, but had no luck with that.
Am I missing something here? Is this happening because the flow runs with different parameters (I have 4 schedules for the same deployment, each with different parameters)?
This "problem" is making some flow runs to fail with the following error message:
Flow run could not be submitted to infrastructure: An error occurred (ClientException) when calling the RegisterTaskDefinition operation: Too many concurrent attempts to create a new revision of the specified family.
@MarvinMarvin
07/16/2025, 8:27 PMMarvin
07/16/2025, 8:28 PMawslogs-stream-prefix)
- Different parameters can trigger new task definition creation
- The match_latest_revision_in_family setting doesn't fully prevent this behavior
2. Current Limitations:
- AWS has a rate limit on the RegisterTaskDefinition operation
- When multiple flows are scheduled close together, this can trigger the "Too many concurrent attempts" error you're seeing
3. Potential Workarounds:
a. Spread Out Schedules: If possible, stagger your schedules to avoid concurrent task definition registrations
b. Use Pre-registered Task Definitions: You can pre-register a task definition and configure your work pool to use it
c. Consolidate Schedules: Consider if you can combine some of your schedules and handle the different parameters within the flow logic instead
4. Best Practice Solution:
Here's how you can modify your work pool configuration to use a pre-registered task definition:
yaml
work_pool:
name: your-ecs-pool
job_variables:
task_definition_arn: "arn:aws:ecs:region:account:task-definition/your-task-definition:1"
family: "your-task-family"
# Other configurations...
The key is to:
1. Pre-register your task definition in AWS ECS
2. Use that task definition's ARN in your work pool configuration
3. Keep the family name consistent
This approach should help you avoid the task definition registration rate limit issues while still allowing you to run your flow with different parameters.
Note: This is an active issue in the Prefect community, and there are ongoing discussions about improving this behavior. You might want to follow this GitHub issue for updates.
Would you like me to provide more specific details about any of these workarounds, or would you like to explore a particular solution further?Jake Kaplan
07/16/2025, 8:35 PMmatch_latest_revision_in_family. But you should definitely not be getting a different revision with every flow run, unless you are making infra level configuration changes dynamically on every single flow run.
It should be using the latest revision for a given workpool/deployment combo at a time. Can you see what the diff is between one task revision and the next in the same family? That should give an idea of why it's generating a new one.
You also always have the option to create your own task definition manually and just pass the arn, then a new revision will never be created.Fernando Müller
07/21/2025, 1:07 PM