Short answer: another process already has this flow run. That log comes from Prefect’s orchestration policy in 3.x. When a runner/worker tries to set a flow run to PENDING but the run is already in PENDING, the server aborts the duplicate transition with: “This run is in a PENDING state and cannot transition to a PENDING state.” This is protective: it prevents two processes from trying to submit the same run. It most often shows up in Kubernetes if: - You have multiple runner/worker pods for the same work pool/queue and they briefly contend for the same run - A pod restarted after proposing PENDING and a second pod picked up the same run - Transient network delays caused two submissions to race What to check - Does the run actually proceed to Submitting/Running in the UI? If yes, this message is harmless noise from the losing contender. - How many replicas of your Prefect worker/runner are you running for this work pool? If more than one, this contention can occur transiently. - Look for the same flow run ID in other pod logs; one of them likely continued the run:

kubectl logs -n <ns> -l app=prefect-worker --since=30m | grep 4cfb903c-f089-4110-abe6-d47329cd22df

- From a pod, you can also verify server health:

curl <http://prefect-server.prefect.svc.cluster.local:4200/api/health>

If this is frequent or runs get “stuck” in PENDING - Ensure only one worker/runner instance is eligible to pick the run at a time (check work pool assignment, queues, and replicas). - Verify your worker pods are not flapping (liveness/readiness probes, resource pressure). - Confirm there aren’t multiple submission paths for the same deployment (e.g., automations plus a manual trigger loop). If you can share a bit more, I can pinpoint it: - Prefect version (assuming 3.x)? - Are you using a deployment + worker? Which worker type (Kubernetes, Docker, Process) and how many replicas? - After this message, does the flow run advance to Running or stay in Pending?