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

The cache should validate that found items were actually created by it / meant for it #22

Open
naderman opened this issue Oct 14, 2016 · 10 comments

Comments

@naderman
Copy link

Q A
Bug? yes
New Feature? no
Version

Actual Behavior

The cache uses any item matching the key and may error if the content does not match what it expects.

Expected Behavior / Possible Solution

The cache should treat an item that was potentially created by another service with a colliding key as a reason to skip caching the resource with this key.

@Nyholm
Copy link
Member

Nyholm commented Oct 14, 2016

Another possible solution would be to treat that cache data as invalid/empty and overwrite it if needed.

@naderman
Copy link
Author

That'd be fine with me too, but may lead to two separate systems continuously overwriting the value

@Nyholm
Copy link
Member

Nyholm commented Oct 14, 2016

Yeah. That is why one would need the PrefixedCache php-cache/cache#96 =)

If we do not overwrite we risk that random garbage data from an other service blocks this cache key forever. That would mean that we never can cache.

@dbu
Copy link
Contributor

dbu commented Oct 15, 2016

i would vote that we implement overwriting then. if you use a different cache instance per service you can already use different paths, and ifnot the PR @Nyholm did will further improve the situation. still, data on a disk could be corrupted for whatever reason (incomplete write, actual disk failure, other types of "this should never happens" errors) so stopping to cache sounds wrong.

@sagikazarmark
Copy link
Member

I think overwriting should be the way to go.

@naderman cache libraries and cache systems usually support namespacing, so avoiding collision is the responsibility of the user to configure it IMO.

@kelunik
Copy link

kelunik commented Nov 13, 2017

IMO it should just fail hard and throw an exception. It's clearly a configuration mistake that needs to be fixed.

@dbu
Copy link
Contributor

dbu commented Nov 13, 2017

its an error, yes, but in production mode you rather want things to survive than a hard exception. it can log an error, or if it can know we are in some sort of dev mode, it can throw an exception.

@kelunik
Copy link

kelunik commented Nov 13, 2017

In that case throw a warning each time and ignore the cache. It ought to be fixed.

@dbu
Copy link
Contributor

dbu commented Nov 13, 2017

yeah agree, trigger a warning level error sounds like the right thing to do.

ignoring the cache in that case could lead to cache stop working at some point down the road if it either got corrupted by a random filesystem accident, or a hard crash mid-writing to the cache, or because we changed the format (maybe by accident, or in a new major version). thus i think overwriting should be ok in that case.

@kelunik
Copy link

kelunik commented Nov 13, 2017

That's a good point, indeed. 👍

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

No branches or pull requests

5 participants