Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache expirations #14035

Merged
merged 8 commits into from
Jun 14, 2024
Merged

Cache expirations #14035

merged 8 commits into from
Jun 14, 2024

Conversation

cicdw
Copy link
Member

@cicdw cicdw commented Jun 14, 2024

Closes #13865

This PR wires up cache expirations by storing an optional expiration timestamp within the PersistedResultBlob that we write to the result store.

@cicdw cicdw requested a review from a team as a code owner June 14, 2024 17:28
Copy link
Member

@desertaxle desertaxle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Just one nit/question on typing.

@@ -187,7 +187,7 @@ def commit(self) -> bool:

def stage(
self,
value: dict,
value: BaseResult,
Copy link
Member

@desertaxle desertaxle Jun 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: value doesn't necessarily need to be a BaseResult right? I find I'm able to stage arbitrary values with the transaction context manager:

from prefect.transactions import transaction


def main():
    with transaction(key="static") as txn:
        if txn.is_committed():
            return txn.read().get() # need .get because txn.read() returns a result
        else:
            value = {"x": 1}
            txn.stage(value)
            return value


if __name__ == "__main__":
    print(main())

That script will print {"x": 1} even if I change value on a subsequent run.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So it's tricky - for the full lifecycle to truly work properly, I do think the record stores should always interact via result payloads. However, that being said, I think the stage -> write functionality will work just fine without staging a true "Result". I changed this type because the moment we use a different record store type (such as Redis), we'll need to persist a serialized Result payload into the record store, which presupposes the value is a prepared result. That probably is a little convoluted, but basically what I'm saying is that right now it works fine because we're overloading the Result interface, but this distinction will become important when we decouple.

@cicdw cicdw merged commit ac39c59 into main Jun 14, 2024
26 checks passed
@cicdw cicdw deleted the cache-expirations branch June 14, 2024 18:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Task cache expiration doesn't seem to function
2 participants