prefect.utilities.engine
Functions
is_prefect_sigterm_handler_installed
can_ack_control_intent
capture_sigterm()
installs and restores Prefect’s SIGTERM bridge. On POSIX, the runner’s
subsequent real SIGTERM is the actual cancellation trigger, so the
child only needs to verify that Prefect still owns the live bridge before
advertising readiness with b"a".
commit_control_intent_and_ack
capture_sigterm() to install and restore Prefect’s SIGTERM
handler. Otherwise, teardown can restore the original handler after the
child decides it is safe to ack but before the runner observes b"a".
collect_task_run_inputs
collect_task_run_inputs_sync
capture_sigterm
TerminationSignal.
Only the outermost Prefect flow engine in a process installs the handler
by default. Nested subflow engines reuse that existing Prefect-owned
handler when it is still active; if user or library code temporarily
replaced SIGTERM, the nested scope reinstalls Prefect’s bridge for the
duration of that scope. This guard is based on explicit local ownership
state plus the currently installed handler, not on FlowRunContext: a
fresh subprocess may hydrate a parent flow context before its own engine
starts, and still needs to install a SIGTERM bridge for the child process.
The handler does not need to interpret intent. The engine’s
except TerminationSignal block consults
prefect._internal.control_listener.get_intent() directly when
dispatching (today: handle_cancellation vs handle_crash; in a
future PR: plus handle_suspension).
The runner control listener only connects while this context is active.
Cancels that land before the bridge is armed fall back to the runner’s
existing crash-style termination path; once this context is active, the
child can acknowledge control intent and treat the later SIGTERM as an
intentional cancellation.
resolve_inputs
Quote, PrefectFuture, or State types nested in parameters into
data.
Returns:
- A copy of the parameters with resolved data
UpstreamTaskError: If any of the upstream states are notCOMPLETED
propose_state
state will be augmented with
details and returned.
If the proposed state is rejected, a new state returned by the Prefect API will be
returned.
If the proposed state results in a WAIT instruction from the Prefect API, the
function will sleep and attempt to propose the state again.
If the proposed state results in an ABORT instruction from the Prefect API, an
error will be raised.
Args:
state: a new state for a flow runflow_run_id: an optional flow run id, used when proposing flow run states
- a State model representation of the flow run state
prefect.exceptions.Abort: if an ABORT instruction is received from the Prefect API
propose_state_sync
state will be augmented with
details and returned.
If the proposed state is rejected, a new state returned by the Prefect API will be
returned.
If the proposed state results in a WAIT instruction from the Prefect API, the
function will sleep and attempt to propose the state again.
If the proposed state results in an ABORT instruction from the Prefect API, an
error will be raised.
Args:
state: a new state for the flow runflow_run_id: an optional flow run id, used when proposing flow run states
- a State model representation of the flow run state
ValueError: if flow_run_id is not providedprefect.exceptions.Abort: if an ABORT instruction is received from the Prefect API
get_state_for_result
link_state_to_result must have been called first.
For objects that support __weakref__, the entry stored by
link_state_to_result carries a weak reference back to the original
object. We verify here that the entry’s weak reference still points
to the same object that registered the entry — not just to some
object that happens to share its id(). This prevents stale hits
caused by CPython recycling a freed memory address. Stale entries
are evicted on detection.
For objects that do not support __weakref__ (plain dict, list,
set, str, int, tuple, …), the entry has no weak reference
and we fall back to the legacy id()-only lookup. This preserves
today’s behavior for those types — including the latent stale-id
bug — and isolates the limitation to a single named code path.
link_state_to_flow_run_result
link_state_to_task_run_result
link_state_to_result
id of the components to map to the state. The cache is persisted to the
current flow run context since task relationships are limited to within a flow run.
This allows dependency tracking to occur when results are passed around.
Note: Because id is used, we cannot cache links between singleton objects.
We only cache the relationship between components 1-layer deep.
Example:
Given the result [1, [“a”,“b”], (“c”,)], the following elements will be
mapped to the state:
- [1, [“a”,“b”], (“c”,)]
- [“a”,“b”]
- (“c”,)
1 will not be mapped to the state because it is a singleton.
Other Notes:
We do not hash the result because:
- If changes are made to the object in the flow between task calls, we can still track that they are related.
- Hashing can be expensive.
- Not all objects are hashable.
- Hash-based keying would also conflate equal-but-distinct objects from unrelated tasks.
__prefect_state__, on the result because:
- Mutating user’s objects is dangerous.
- Unrelated equality comparisons can break unexpectedly.
- The field can be preserved on copy.
- We cannot set this attribute on Python built-ins.
should_log_prints
check_api_reachable
emit_task_run_state_change_event
resolve_to_final_result
PrefectFuture, or State types nested in parameters into
data. Designed to be use with visit_collection.
resolve_inputs_sync
Quote, PrefectFuture, or State types nested in parameters into
data.
Returns:
- A copy of the parameters with resolved data
UpstreamTaskError: If any of the upstream states are notCOMPLETED