Different application root locations result in different cache keys

The Caller context key strategy employs the calling code's full file path in generating a cache key. Our environment is run from heterogeneous servers at different file paths, so we discovered that one environment would continue to fetch stale cache values after an invalidation occurred in a different environment.

The operative lines are here:

garner/lib/garner/strategies/context/key/caller.rb

Line 21 in 1dd40d9

ruby_context.send(:caller).each do |line|

Example of the different results:

caller[0].split(':')[0]  # => "/app/app/api/api.rb" on Heroku
caller[0].split(':')[0]  # => "/srv/www/myapp/releases/20130612030626/app/api/api.rb" on OpsWorks

I think that Garner can't do much here. I suggest rolling out a custom strategy that cuts off the caller path at app.

I think the best approach is to configure a Garner.config.application_root (or, if we want to be specific, Garner.config.caller_root). This can then be grepped and removed from caller lines.

We can default this to Rails.root if we're in a Rails environment, kinda like we do with Garner.config.cache and Rails.cache.

👍

I second that maybe including just the filename / line number (or as @dblock pointed out- just the part of the full path that should be the same across environments) might be a good fix while still being able to cache differently based on whether this was from a view, or a controller, etc.

The caveat being as long as we can reasonably determine that root 'cut off' for Rails and non-Rails environments.

Thanks for the report and suggestions. I'll take this one.

@fancyremarker beat me to it.

Trying to 'close' a comment box and hit 'close' on the issue by accident.