@Marvin When a worker picks up a new flow run, does it prioritise the run thats been waiting the longest or the most recent one?

When a worker picks up a new flow run, it prioritizes based on the defined priority of the work queue rather than the waiting time of the flow runs. Here’s the prioritization logic: 1. Priority of Work Queues: Flow runs are submitted for execution based on the priority of their respective work queues, from the highest to the lowest priority. 2. Concurrency Limits: If concurrency limits are not preventing execution, the priority still determines the order of submission without impacting execution. 3. Critical Queues: Urgent work (such as unplanned backfills) in higher-priority queues will be executed before any work in lower priority queues. For more details, you can refer to the Prefect documentation on work pools.

@Marvin Lets assume the concurrency limit is set to one and all are runs are from the same flow with equal priority

When the concurrency limit is set to one and all flow runs have the same priority and are from the same flow, the worker's scheduling behavior would generally follow a First-In, First-Out (FIFO) approach. This means the flow run that has been waiting the longest is likely to be picked up next. For more precise control, you can configure work queue priorities and concurrency limits. Here are some specifics: - Order of Submission: Flow runs are submitted for execution in the order they arrived if they have identical priority and no other constraints. - Concurrency Limitations: If only one run can be executed at a time (due to a concurrency limit of one), the waiting runs will queue up based on their arrival times. For more information, you can refer to the Prefect documentation on work pools.