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

Revalidation #2700

Open
mnot opened this issue Dec 8, 2023 · 2 comments
Open

Revalidation #2700

mnot opened this issue Dec 8, 2023 · 2 comments

Comments

@mnot
Copy link
Member

mnot commented Dec 8, 2023

The ability to group for purposes of revalidation was added somewhat speculatively. We should evaluate it and see if it's useful, safe, etc.

@mnot
Copy link
Member Author

mnot commented Feb 20, 2024

Perhaps what we should do is remove revalidation, but assure that tags can be extended in a way that allows future uses like that to be safely specified.

@MikeBishop
Copy link
Contributor

I'm inclined to say this is dangerous as-is.

Assume the deployment of a batch of resources has a file in it which does not always change with every release. If that resource is the first one to be revalidated, the lifetime of the stale resources is extended and the stale copies continue to be served. The cache will then fail to discover that they have changed, because it won't attempt to revalidate them.

If you want to do this, I think you need something like a group ETag, where the revalidation can indicate that this resource hasn't changed, but the state of the group has.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants