<@ULVA73B9P> - Prefect worker cli always start wor...
# ask-marvin
c
@Marvin - Prefect worker cli always start worker with default worker queue option, even though i haven't provided the --worker-queue option. Due to this flows are always starting on default even though other queue ar configured
m
thought for 158.4 seconds
What you’re seeing is expected worker behavior in Prefect 3.x, but probably not the root cause you think it is. Key point: If you start a worker without
--work-queue
, the worker will poll all queues in the work pool — not just
default
. So this:
Copy code
bash
prefect worker start --pool my-pool
means:
Copy code
text
poll every queue in my-pool
not:
Copy code
text
poll only the default queue
I verified the CLI help for
prefect worker start
, and
--work-queue/-q
is optional specifically to restrict which queues the worker pulls from. Most likely, your deployments are being assigned to the
default
queue because
work_queue_name
was not set when deploying. Common cause If your deployment config looks like this:
Copy code
yaml
deployments:
  - name: my-deployment
    work_pool:
      name: my-pool
then Prefect will use the pool’s default queue unless you explicitly set:
Copy code
yaml
deployments:
  - name: my-deployment
    work_pool:
      name: my-pool
      work_queue_name: my-other-queue
Or in Python:
Copy code
python
my_flow.deploy(
    name="my-deployment",
    work_pool_name="my-pool",
    work_queue_name="my-other-queue",
)
How to confirm Check your deployment in the UI or inspect it via CLI and see which queue it is assigned to. If it says
default
, then the worker is just correctly picking up runs from that queue. If you want queue-specific workers Start workers like this:
Copy code
bash
prefect worker start --pool my-pool --work-queue queue-a
or multiple queues:
Copy code
bash
prefect worker start --pool my-pool --work-queue queue-a --work-queue queue-b
Summary - No
--work-queue
on the worker => worker polls all queues in the pool - No
work_queue_name
on the deployment => deployment usually goes to the pool’s
default
queue - So flows running on
default
usually means the deployment is targeting
default
Relevant docs: - Worker CLI docs - prefect.yaml deployment config If you want, paste your
prefect.yaml
or deployment code and I can point out exactly where the queue is being set to
default
.
c
during worker starts, worker is polling only default queue and other queues are showing as Not ready, even though the worker is online. worker queue doesn't have any actively polling workers ready to execute work. This is message i see on worker queue info button
@Marvin - during worker starts, worker is polling only default queue and other queues are showing as Not ready, even though the worker is online. worker queue doesn't have any actively polling workers ready to execute work. This is message i see on worker queue info button
m
thought for 259.9 seconds
Thanks — that extra detail changes the diagnosis. If the UI says for non-default queues:
Copy code
text
This work queue doesn't have any actively polling workers ready to execute work
that means those queues are not being polled, even if the worker itself is online. Important distinction: - Worker online = worker heartbeat is being received - Queue ready = that specific queue is being polled for scheduled flow runs Those are not the same thing in Prefect 3.x. What should happen normally If you start a worker with no queue restriction:
Copy code
bash
prefect worker start --pool my-pool
it should poll all queues in that pool, and those queues should become ready. If only
default
becomes ready and the others stay
Not ready
, then usually one of these is true: 1. The worker is actually restricted to the default queue For example, it may have been started with:
Copy code
bash
prefect worker start --pool my-pool --work-queue default
or equivalent env/config values. 2. The worker is connected to a different work pool than the queues you’re checking A worker only polls queues in its own pool. 3. The worker has not yet successfully polled those queues Heartbeat alone does not mark queues ready. What to check Check the actual worker start command Make sure it really does not include
-q default
/
--work-queue default
. Verified CLI syntax:
Copy code
bash
prefect worker start --help
shows
--work-queue/-q
is optional, and if set, it limits the queues polled. Check the worker’s pool Make sure the worker is started against the same pool where those queues exist. Inspect the queues You can list queues with:
Copy code
bash
prefect work-queue ls
and inspect one with:
Copy code
bash
prefect work-queue inspect <queue-id>
CLI help for work queues: - Work queue CLI docs Most likely explanation Based on your description, the most likely issue is that the worker is effectively polling only
default
— either because: - it was started with a queue filter, or - the environment/config supplying the worker command is injecting that queue filter. If you’re running the worker via Docker, Helm, Kubernetes, systemd, or some wrapper script, double-check the real command being executed. What I’d try next Start a worker explicitly against the queues you want:
Copy code
bash
prefect worker start --pool my-pool --work-queue default --work-queue queue-a --work-queue queue-b
If that makes those queues become ready, then we’ve confirmed it’s a queue-selection/config issue. If you want, send me: - the exact worker start command - whether you’re using Cloud or Server - whether this is Docker/Kubernetes/Helm/local - output of
prefect version
and I can help narrow down why only
default
is being polled.
c
kp_alive