Retrieve results
When calling flows or tasks, the result is returned directly:State.result()
method:
Future.result()
method:
Handling failures
Prefect captures all exceptions to report states to the orchestrator, but we do not hide them from you (unless you ask us to) as your program needs to know if an unexpected error has occurred. When calling flows or tasks, the exceptions are raised as in normal Python:try/except
, you may ask Prefect to return the state:
Future.result()
works the same as State.result()
:
Working with async results
When calling flows or tasks, the result is returned directly:State.result()
method:
Resolving resultsPrefect 2.6.0 added automatic retrieval of persisted results.
Prior to this version,
State.result()
did not require an await
.
For backwards compatibility, when used from an asynchronous context, State.result()
returns a raw result type.You may opt-in to the new behavior by passing fetch=True
as shown in the example above.
To use this behavior automatically, you may enable the PREFECT_ASYNC_FETCH_STATE_RESULT
setting.
If you do not opt-in to this behavior, you will see a warning.You may also opt out by setting fetch=False
.
This will silence the warning, but you will need to retrieve your result manually from the result type.Future.result()
method:
Persisting results
The Prefect API does not store your results except in special cases. Instead, the result is persisted to a storage location in your infrastructure and Prefect stores a reference to the result. The following Prefect features require results to be persisted:- Task cache keys
- Flow run retries
Configure persistence of results
Persistence of results requires a serializer and a storage location. Prefect sets defaults which you can adjust for custom behavior. You can configure results on theflow
and task
decorators with the following options:
persist_result
: Whether the result should be persisted to storage.result_storage
: Where to store the result when persisted.result_serializer
: How to convert the result to a storable form.
Toggling persistence
Configure the persistence of the result of a task or flow with thepersist_result
option.
The persist_result
option defaults to a null value, which automatically enables persistence if it is
needed for a Prefect feature used by the flow or task. Otherwise, persistence is disabled by default.
For example, the following flow has retries enabled. Flow retries require that all task results are persisted,
so the task’s result will be persisted:
PREFECT_RESULTS_PERSIST_BY_DEFAULT
setting.
To persist results by default, change the value to a truthy value:
persist_result=False
will not persist their results even
if PREFECT_RESULTS_PERSIST_BY_DEFAULT
is true
.
Result storage location
Configure the result storage location with theresult_storage
option.
The result_storage
option defaults to a null value, which infers storage from the context.
Generally, this means that tasks will use the result storage configured on the flow unless otherwise specified.
If there is no context to load the storage from and results must be persisted,
results will be stored in the path specified by the PREFECT_LOCAL_STORAGE_PATH
setting (defaults to ~/.prefect/storage
).
- A storage instance. For example,
LocalFileSystem(basepath=".my-results")
- A storage slug. For example,
's3/dev-s3-block'
Result storage key
Configure the path of the result file in the result storage with theresult_storage_key
.
The result_storage_key
option defaults to a null value, which generates a unique identifier for each result.
prefect.runtime
and the run’s parameters
.
The following example runs a flow with three runs of the same task.
Each task run will write its result to a unique file based on the name
parameter.
prefect.runtime.flow_run
module:
Result serializer
You can configure the result serializer with theresult_serializer
option.
The result_serializer
option defaults to a null value, which infers the serializer from the context.
Generally, this means that tasks will use the result serializer configured on the flow unless otherwise specified.
If there is no context to load the serializer from, the serializer defined by PREFECT_RESULTS_DEFAULT_SERIALIZER
is used. This setting defaults to Prefect’s pickle serializer.
You may configure the result serializer using:
- A type name. For example,
"json"
or"pickle"
which corresponds to an instance with default values - An instance. For example,
JSONSerializer(jsonlib="orjson")
Compress results
Prefect provides aCompressedSerializer
which can wrap other serializers to provide
compression over the bytes they generate. The compressed serializer uses lzma
compression by default.
We test other compression schemes provided in the Python standard library such as bz2
and zlib
,
but any compression library that provides compress
and decompress
methods should work.
Configure compression of results using:
- A type name, prefixed with
compressed/
. For example,"compressed/json"
or"compressed/pickle"
- An instance. For example,
CompressedSerializer(serializer="pickle", compressionlib="lzma")
"compressed/<serializer-type>"
shortcut will only work for serializers provided by Prefect.
If you are using custom serializers, you must pass a full instance.
Storage of results in Prefect
The Prefect API does not store your results in most cases for the following reasons:- Results can be large and slow to send to and from the API.
- Results often contain private information or data.
- Results would need to be stored in the database or complex logic implemented to hydrate from another source.
- booleans (
True
,False
) - nulls (
None
)
persist_result
is set to False
, these values will never be stored.
Track results
The Prefect API tracks metadata about your results. The value of your result is only stored in specific cases. View result metadata in the UI on the “Results” page for flows. Prefect tracks the following result metadata:- Data type
- Storage location (if persisted)
Caching of results in memory
When running your workflows, Prefect keeps the results of all tasks and flows in memory so they can be passed downstream. In some cases, it is desirable to override this behavior. For example, if you are returning a large amount of data from a task, it can be costly to keep it in memory for the entire duration of the flow run. Flows and tasks both include an option to drop the result from memory withcache_result_in_memory
:
cache_result_in_memory
is disabled, the result of your flow or task will be persisted by default.
The result is then pulled from storage when needed.
cache_result_in_memory
and persistence are disabled, your results are not available downstream.
Result storage types
Result storage is responsible for reading and writing serialized data to an external location. You can use any file system block for result storage.Result serializer types
A result serializer is responsible for converting your Python object to and from bytes. This is necessary to store the object outside of Python and retrieve it later.Pickle serializer
Pickle is a standard Python protocol for encoding arbitrary Python objects. We supply a custom pickle serializer atprefect.serializers.PickleSerializer
.
Prefect’s pickle serializer uses the cloudpickle
project by default to support more object types.
You can specify alternative pickle libraries, such as:
- Many object types are supported.
- Objects can define custom pickle support.
- When nested attributes of an object cannot be pickled, it is hard to determine the cause.
- When deserializing objects, your Python and pickle library versions must match the one used at serialization time.
- Serialized objects cannot be easily shared across different programming languages.
- Serialized objects are not human readable.
JSON serializer
We supply a custom JSON serializer atprefect.serializers.JSONSerializer
.
Prefect’s JSON serializer uses custom hooks by default to support more object types.
Specifically, we add support for all types supported by Pydantic.
By default, we use the standard Python json
library. You can specify alternative JSON libraries, such as:
- Serialized objects are human readable.
- You can share serialized objects across different programming languages.
- Deserialization of serialized objects is generally version agnostic.
- Supported types are limited.
- You must implement support for additional types at the serializer level.
Result types
Prefect uses internal result types to capture information about the result attached to a state. The following types are used:UnpersistedResult
: Stores result metadata but the value is only available when created.LiteralResult
: Stores simple values inline.PersistedResult
: Stores a reference to a result persisted to storage.
get()
method that can be called to return the value of the result.
This is done behind the scenes when the result()
method is used on states or futures.
Unpersisted results
Unpersisted results represent results that are not persisted beyond the current flow run. The value associated with the result is stored in memory, but is not available later. Result metadata is attached to this object for storage in the API and representation in the UI.Literal results
Literal results represent results stored in the Prefect database. The values contained by these results must be JSON serializable. Example:Persisted results
The persisted result type contains all of the information needed to retrieve the result from storage. This includes:- Storage: A reference to the result storage to read the serialized result.
- Key: Indicates where this specific result is in storage.
- Serializer type: The name of the result serializer type.
get()
method on result references retrieves the data from storage, deserializes it, and returns the original object.
The get()
operation caches the resolved object to reduce the overhead of subsequent calls.
Persisted result blob
When results are persisted to storage, they are always written as a JSON document. The schema for this is described by thePersistedResultBlob
type. The document contains:
- The serialized data of the result.
- A full description of result serializer to deserialize the result data.
- The Prefect version used to create the result.