Yes — in Prefect 3.7.1 there is a mechanism that can put a flow run into

AwaitingRetry

even if Kubernetes itself is not retrying the Job. The main ones are: 1. Flow-level retries configured in Prefect If the flow or deployment has

retries

set, Prefect orchestration can convert a failure into

AwaitingRetry

. Example:

`
@flow(retries=3, retry_delay_seconds=60)
def my_flow():
    ...
`

So

backoffLimit=0

only stops *Kubernetes Job retries*; it does not stop Prefect flow retries. 2. SIGTERM reschedule behavior In Prefect 3.x, when a flow-run process gets

SIGTERM

, Prefect can intentionally move the run to

AwaitingRetry

if

PREFECT_FLOW_RUN_EXECUTE_SIGTERM_BEHAVIOR=reschedule

. This is especially relevant on Kubernetes when pods are being: - evicted - terminated during node scaling - killed by rollout/preemption - otherwise receiving

SIGTERM

And there’s an important wrinkle: The Kubernetes worker may set

PREFECT_FLOW_RUN_EXECUTE_SIGTERM_BEHAVIOR=reschedule

automatically when

backoffLimit=0

, if that env var is not already set. So if it was “disabled” by leaving it blank/unset, that may not actually disable it. What matters is that it is explicitly set to a non-

reschedule

value. For example:

`
PREFECT_FLOW_RUN_EXECUTE_SIGTERM_BEHAVIOR=cancel
`

or

`
PREFECT_FLOW_RUN_EXECUTE_SIGTERM_BEHAVIOR=die
`

If the variable is unset or empty, the worker can still inject

reschedule

. What I’d check first 1. Check whether the flow/deployment has Prefect retries configured -

@flow(retries=...)

- deployment-level retry settings - any defaults coming from deployment config 2. Check the actual env inside the running flow pod

`
kubectl exec <pod-name> -- env | grep PREFECT_FLOW_RUN_EXECUTE_SIGTERM_BEHAVIOR
`

If you see

reschedule

, that explains the

AwaitingRetry

. 3. Check whether the pod is getting SIGTERM / evicted

`
kubectl describe pod <pod-name>
`

Look for events like eviction, scale-down, preemption, termination, etc. 4. Confirm the actual Job spec

`
kubectl get job <job-name> -o yaml
`

Verify

backoffLimit: 0

is really present on the created Job. Important distinction -

backoffLimit=0

=> Kubernetes won’t retry the Job -

AwaitingRetry

=> Prefect orchestration intends to retry/reschedule the flow run Those are separate layers. My best guess from what you described If runs are repeatedly going to

AwaitingRetry

“from an unknown source”, the most likely causes are: - the flow/deployment has Prefect retries configured, or - the pod is receiving SIGTERM and Prefect is rescheduling it via

PREFECT_FLOW_RUN_EXECUTE_SIGTERM_BEHAVIOR=reschedule

If you want, I can help you narrow this down from: - your flow decorator / deployment config - your work pool job template - the pod env + pod events output No GitHub issue/discussion links were available because GitHub search failed on my side just now, but the behavior above was verified from Prefect source.