Short answer: your worker tried to submit a flow run by proposing a Pending state, but the server already had that run in Pending. The server rejects “Pending → Pending” as an invalid state transition, so the worker logs an aborted submission. Why this happens - Two workers raced to claim the same run; one succeeded, the other backed off. - A client/network timeout occurred after the first submission succeeded on the server; the worker retried the submission and hit the “already Pending” guard. - Less commonly: a worker restart or task in-process retry can create similar patterns. Is it a problem? - If you just see this once or twice and another log shows the run starting on a worker, it’s benign. - If you see repeated “aborted submission” messages in a loop and no worker actually starts the run, then something’s off (e.g., worker restart, timeout/retry loop, or a bug). What to check / do - Confirm one worker actually started the run around the same time (look for “Started flow run …” in worker logs). - If you suspect timeouts, increase the worker’s API request timeout:

PREFECT_API_REQUEST_TIMEOUT=60

- If you run multiple workers on the same pool, occasional race logs are expected. If it’s frequent, review pool/worker limits and network latency. - If a worker gets “stuck” after aborting (e.g., “Flow run limit reached; 1 flow runs in progress.” forever), restart that worker; there’s an open bug tracking that scenario: Issue #15952. - If a run is truly stuck and never starts, cancel and re-run; also restart the worker(s). Related references - “This run is in a PENDING state and cannot transition to a PENDING state” due to timeout/retry: Issue #10263 - Worker concurrency sticking after aborted submission (Prefect 3.x): Issue #15952 - Similar retry-related behavior (mostly 2.x context): Issue #16126 If you can share: - Prefect version, worker type (e.g., Process/Docker/Kubernetes), number of workers on the pool - Whether this is a one-off message or a repeating loop - A short log snippet around the event …I can help pinpoint which of the causes above fits your case and the best fix.