Check out results for more details:https://docs.prefect.io/core/concepts/results.html#results
object, which is in memory, and therefore short lived. The persisting output section notes that you need a
object to explicitly specify where and how your data will be stored.
isn't good enough. First run notes that the cache is invalid, and runs tasks normally. Subsequent runs mark the task as cached, meaning a cache has been found, but passes
to downstream tasks, failing the flow. Adding a
parameter, specifically a
object made the non-cached task run persist its output, and subsequent runs used the cached value successfully. Here is what I think is going on: A
merely exists as a way to persist task outputs to somewhere. It does not have to be involved with caching. For prefect core runs, the cache is simply
configurations aren't involved here at all. For server/cloud runs, the cache is stored on the API side. But the cached value is not the data itself, but the
objects location. If the server API determines that a task has a valid cache, the cached location is used, alongside your
configuration, to retrieve the actual value of your data.
bridge the gap between the API and your runtime environment. Since the API is designed to maintain separation from your data, we need a way to tell the API where the data is stored in your own infrastructure.