@Marvin thoughts?

Could you share a bit more context on what you want thoughts on? For example: - a Prefect architecture or deployment setup - an error message - some code - a workflow design decision - pricing / plan choice - a GitHub issue or discussion If you paste the snippet, config, screenshot text, or question, I can give a concrete opinion.

@Marvin please explain how

pause_flow_run

in the SDK uses the API

aka we just sleeps it for 100 seconds

- description - later, the actual response Conceptually, the keys are derived from the pause state / pause key, with entries like: -

...-schema

-

...-description

-

...-response

So before the run is paused, the SDK persists enough metadata for the API to validate the eventual resume payload. ### Why this matters This means the API can enforce that a resume request provides input matching the expected schema, instead of blindly accepting arbitrary JSON. --- ## What the SDK does while the run is paused After the API accepts the

PAUSED

state, the SDK does not “return immediately and forget everything”. Instead, it waits by polling the flow run state periodically. Conceptually:

text
while flow run state is PAUSED:
    sleep(poll_interval)
    fetch current flow run state

When the run leaves the paused state, the SDK continues. If

wait_for_input

was used, it then retrieves the stored response and returns it from

pause_flow_run()

. So from the flow author’s perspective, it behaves like a blocking pause point:

python
approval = pause_flow_run(wait_for_input=Approval)
# execution resumes here after API-side resume

--- ## How resume works at the API level Resume happens through a dedicated endpoint:

text
POST /flow_runs/{id}/resume

This is separate from

set_state

. The server does roughly this: 1. Confirms the flow run is currently paused 2. If input is supplied, finds the saved schema via the

run_input_keyset

3. Validates the provided input against that schema 4. Stores the validated response in flow run input storage 5. Transitions the run out of

PAUSED

If

pause_reschedule=False

(normal pause), resume transitions the run to something like: -

Running()

If

pause_reschedule=True

(more like suspend/reschedule behavior), resume may transition it through: -

Scheduled(name="Resuming")

That distinction matters because some pauses are meant to continue in-place, while others are intended to be rescheduled onto infrastructure. --- ## Resume with input: validation flow When input is passed to the resume endpoint, the API does schema-driven validation. The pattern is: 1. Read saved schema from flow-run input storage 2. Validate submitted

run_input

against schema 3. Reject the resume if validation fails 4. Save the validated response under the response key if validation succeeds So the API is not trusting the client to validate correctly; the validation happens server-side too. That’s a strong design choice because it keeps the pause/resume contract authoritative at the API layer. --- ## Endpoints involved The main API endpoints involved are: ### Pause via state orchestration

text
POST /flow_runs/{id}/set_state

Used to propose the

PAUSED

state. ### Flow run input storage

text
POST /flow_runs/{id}/input

Used to store: - schema - description - response ### Resume endpoint

text
POST /flow_runs/{id}/resume

Used to: - validate any provided input - store the response - transition the flow run out of

PAUSED

--- ## Relevant models/concepts The important pieces are: -

Paused

state The SDK-side state object used to represent a pause request. -

StateDetails

Holds pause metadata like: -

pause_key

-

pause_timeout

-

pause_reschedule

-

run_input_keyset

-

OrchestrationResult

Returned by the state orchestration endpoint to indicate whether the transition was accepted. - Flow run input records Used to store expected schema and actual resumed input. --- ## Practical summary In one sentence:

pause_flow_run()

uses the API by proposing a

PAUSED

state through

/flow_runs/{id}/set_state

, optionally persisting input schema via

/flow_runs/{id}/input

, then waiting until

/flow_runs/{id}/resume

transitions the run back out of pause. Or even shorter: - Pause = orchestrated state transition to

PAUSED

- Input contract = stored as flow-run input records

- Resume = dedicated API endpoint that validates input and moves state forward --- ## A subtle but useful takeaway

pause_flow_run()

is not just a local Python control-flow primitive. It’s really an orchestrated API-backed checkpoint. That’s why it can support: - UI/API-driven resumes - validated human input - timeout handling - stateful pause identity via

pause_key

--- If you want, I can also give you: - a sequence diagram of the pause/resume API calls, or - a minimal code example showing

pause_flow_run(wait_for_input=...)

and what the corresponding API interactions look like.

note that the flow calls a task

@Marvin does this works in prefect 3.0.11

Yes —

pause_flow_run()

does exist and works in Prefect 3.0.11. Based on the code and API for that version, 3.0.11 includes: -

pause_flow_run

-

resume_flow_run

-

POST /flow_runs/{id}/set_state

-

POST /flow_runs/{id}/resume

- flow-run input support for

wait_for_input=...

So the overall pause/resume mechanism I described does apply to 3.0.11. ## What is supported in 3.0.11 In 3.0.11,

pause_flow_run()

can: - pause a flow run by proposing a

PAUSED

state - optionally wait for typed input with

wait_for_input=...

- resume via the API/UI - validate resume input against stored schema - continue execution after resume ## Important caveats for 3.0.11 A few version-specific notes: - Default timeout is 1 hour (

3600

seconds), unless you override it. - There is a distinction between blocking pause and rescheduling/suspend-like behavior. - In 3.0.11, this functionality is implemented with the older

@sync_compatible

pattern internally; that’s fine, just an internal implementation detail. - One notable limitation in 3.0.11: pausing from within a task was not yet fixed there. That last point matters a lot: ### In 3.0.11, pausing from a task is a problem A later fix changed

pause_flow_run()

so it could pause the parent flow when called inside a task. That fix came later, not in 3.0.11. So in 3.0.11: - calling

pause_flow_run()

inside a flow → yes, expected to work - calling

pause_flow_run()

inside a task → likely not supported / may raise an error like

Cannot pause task runs

## Bottom line Yes, it works in 3.0.11 if you mean the standard flow pause/resume behavior. But if your use case is: - pausing from inside a task - or relying on newer UX fixes around pause input forms then 3.0.11 may be too old. ## Useful links - Prefect repo: Prefect on GitHub - Later fix for pause-from-task behavior: PR #19457 - Example related issue/bug around pause input UX in newer versions: Issue #21491 If you want, I can also answer this more concretely for your exact usage: - pause inside a flow - pause inside a task - pause with

wait_for_input

- resume via UI vs API