https://prefect.io logo
Join Slack
Powered by
<@ULVA73B9P>: My work pool has a flow run concurre...
# marvin-ai
c
@Marvin: My work pool has a flow run concurrency value of 5. Which flow run states use up a slot of this limit?
m
✅ thought for 73.1 seconds
For a work pool flow-run concurrency limit in Prefect 3.x, the states that count against the limit are: - 
PENDING
- 
RUNNING
So if your work pool limit is 
5
, any combination of 5 flow runs in 
PENDING
and/or 
RUNNING
 will use all available slots. A few important notes: - 
SCHEDULED
does not consume a slot - Terminal states like 
COMPLETED
, 
FAILED
, 
CANCELLED
, 
CRASHED
do not consume a slot - 
CANCELLING
is a bit special: it can matter for work queue limits, but for the work pool limit the key states are 
PENDING
and 
RUNNING
Typical lifecycle example: - 
SCHEDULED
→ no slot used - 
PENDING
→ slot acquired - 
RUNNING
→ slot still occupied - 
COMPLETED
/ 
FAILED
/ 
CANCELLED
→ slot released So the short answer is: only flow runs in 
PENDING
or 
RUNNING
use a work pool concurrency slot. If you want, I can also explain how this differs from deployment concurrency limits or work queue concurrency limits.
c
@Marvin: Is this equally true of Prefect 2.x?
m
✅ thought for 126.4 seconds
Yes — for Prefect 2.x, this is true as well for work pool concurrency limits. In 2.x, the states that count against work pool / work queue concurrency were: - 
PENDING
- 
RUNNING
So in that respect, 2.x work pool behavior matches 3.x work pool behavior. The main nuance is in 3.x work queues, where 
CANCELLING
may also be treated as slot-occupying. That distinction does not appear to apply the same way in 2.x. So the concise comparison is: - Prefect 2.x work pool: 
PENDING
, 
RUNNING
- Prefect 3.x work pool: 
PENDING
, 
RUNNING
If you'd like, I can also give you a quick table comparing 2.x vs 3.x across work pools, work queues, and deployment concurrency.
c
@Marvin: Yes, please.
m
✅ thought for 5.6 seconds
Here’s a quick comparison table: | Limit type | Prefect 2.x | Prefect 3.x | |---|---|---| | Work pool concurrency | 
PENDING
, 
RUNNING
| 
PENDING
, 
RUNNING
| | Work queue concurrency | 
PENDING
, 
RUNNING
| 
PENDING
, 
RUNNING
, 
CANCELLING
| | Deployment concurrency | 
PENDING
, 
RUNNING
| 
PENDING
, 
RUNNING
| A couple of takeaways: - Work pool concurrency is effectively the same in 2.x and 3.x - The main change is work queue concurrency in 3.x, where 
CANCELLING
can also hold a slot - Deployment concurrency remains based on active execution states like 
PENDING
and 
RUNNING
So if you’re reasoning about “why can’t another run start?”, in: - 2.x: check for 
PENDING
+ 
RUNNING
- 3.x work pools: check for 
PENDING
+ 
RUNNING
- 3.x work queues: check for 
PENDING
+ 
RUNNING
+ possibly 
CANCELLING
If you want, I can also show where to inspect this in the UI / API for a specific work pool or queue.
c
@Marvin: Yes, please, for Prefect 2.x, please.
m
✅ thought for 146.9 seconds
For Prefect 2.x, the practical way to inspect this is: 1. Look at the configured limit on the work pool / work queue 2. Look at the flow runs in that pool/queue that are in 
PENDING
or 
RUNNING
Those are the runs consuming slots. CLI These commands are available in 2.x: - 
prefect work-pool ls
- 
prefect work-pool inspect
- 
prefect work-queue ls
- 
prefect work-queue inspect
- 
prefect work-queue read-runs
- 
prefect flow-run ls
- 
prefect flow-run inspect
Examples:
Copy code
bash
# See work pools and their concurrency limits
prefect work-pool ls

# Inspect one work pool
prefect work-pool inspect "my-pool"

# List work queues
prefect work-queue ls

# Inspect one queue (by ID)
prefect work-queue inspect <work-queue-id>

# Read runs for a queue
prefect work-queue read-runs <work-queue-id>

# List recent flow runs
prefect flow-run ls

# Inspect a specific flow run
prefect flow-run inspect <flow-run-id>
What to look for: - On the pool/queue object: 
concurrency_limit
- On the flow runs: state type - Count the runs in: - 
PENDING
- 
RUNNING
That count is your slot usage in Prefect 2.x. UI In Prefect 2.x UI: - Go to Work Pools - Open the relevant pool - Check its configured 
concurrency_limit
- Open the associated work queues - Review recent flow runs for that queue/pool - Count runs in 
PENDING
and 
RUNNING
If the UI doesn’t show a direct “slots used” metric, the reliable interpretation is still: - slots in use = number of runs in 
PENDING
+ 
RUNNING
for that pool/queue Python API If you want to inspect this programmatically:
Copy code
python
from prefect import get_client

async def inspect():
    async with get_client() as client:
        pool = await client.read_work_pool("my-pool")
        print("pool limit:", pool.concurrency_limit)

        queues = await client.read_work_queues(work_pool_name="my-pool")
        for q in queues:
            print(q.name, q.concurrency_limit)
Then query flow runs for the relevant queue/pool and count the ones in 
PENDING
and 
RUNNING
. One caveat: I can verify the top-level CLI commands exist, but I wasn’t able to fully verify every subcommand’s argument syntax from the tool environment due timeouts, so if you want, I can help you with the exact command for your version if you share: - your Prefect version - whether you want to inspect by pool or by queue
Open in Slack
PreviousNext
Powered by