Sprockets 3.3.X using old cached files

[juliantai]

When I run cap staging deploy or RAILS_ENV=staging bundle exec rake assets:precompile on my staging/production server I get an old cached version of files I have modified.

Changing the Rails.config.assets.version causes the cache to be invalidated as expected.

Downgrading to 3.2.0 and lower fixes the issue.

I did some digging and it look like my issue is coming from Loader module.

[schneems]

Use 3.3.4

[juliantai]

Thanks! I tried 3.3.4 and it fixes the caching issue.

Regarding deploying to production it looks like it is still looking for files in old folders. I tried to running RAILS_ENV=production rake assets:clean, but it didn't work.

Will I need to run RAILS_ENV=production rake assets:clobber to fix this issue?

Note the date is from a couple days ago as opposed to being today's date 20150902XXXXXX.
DEBUG [5ee0e4cf] Errno::ENOENT: No such file or directory @ rbsysopen - /home/deployer/apps/map_app/releases/20150827232656/app/assets/images/ajax-50x50.png DEBUG [5874e899]

Edit: I updated the config.assets.version in my production.rb file and it fixed it.

[schneems]

💥

[schneems]

Thanks for the report, i'm glad it's working for you now.

I think there still might be a bug here. Part of the cache key includes the version of sprockets that was used when you compiled so i'm not sure why you had to rev the version.

[joker-777]

Hi, we experiencing the same issue. Unfortunately updating to 3.3.4 doesn't help us. Also updating the assets.version only helps for the next deploy which obviously takes quite long. The next deploy after this has again this problem

[juliantai]

Yeah I found that out the next day. I ended up using 3.2.0 for now.

[schneems]

I re-opened the issue. Can either of you give me an example app that reproduces the problem? I can't fix what I can't reproduce, an example app would be hugely helpful.

[wlipa]

I was able to reproduce the problem under 3.3.4 with a scenario like the following:

app/assets/outer.js
//= require inner.js

rake assets:clobber
deploy app
works properly
make a change A to inner.js
deploy app
works properly, the change was picked up
make a change B to inner.js
deploy app
broken, we are still serving up outer.js with embedded inner.js change A, even though change B is actually in the deployed files

It's part of a big app so it's hard to minimize. I'm happy to add log statements or debug it further if you can suggest things to look for.

[joker-777]

I will try to create an example app the next days. Will come back then.

[alepore]

i also have this problem with both 3.3.3 and 3.3.4. but didn't investigate much yet

[joker-777]

@schneems I'm still trying to create an example app but couldn't reproduce it yet. I have one question thought. We still use the old extension format file.js.coffee for our coffeescript files. Could this be a problem?

[wlipa]

I discovered that rake assets:clobber wasn't actually clobbering the assets in my deployed environment (see #140), but unfortunately the stale asset problem still happens even with a manual clobber.

It's quite reproducible in the deployed environment, but does not reproduce on my local dev box, even with the exact same revisions and with the Rails env set to the deployed environment temporarily.

[jeremy]

@wlipa You may be able to reproduce in development by making a copy of your app dir, symlinking the copy's tmp/cache and public/assets to the original tmp/cache and public/assets, then making a change to an asset in the copy and trying to precompile. That mirrors a Capistrano style deploy where a new release directory is seeing cached assets rooted in the previous release directory.

[wlipa]

Thanks for the suggestion. I tried that but it still works correctly on my dev box.

[wlipa]

One thing I find rather baffling is the way that cached dependencies contain references to the deployment release. For example:

file-digest:///home/ops/apps/alpha.example.com/releases/20150922215431/app/assets/javascripts/preferences.js

Doesn't referring directly to old releases that are still on the filesystem mean that we aren't picking up changes to these assets, because the dependency resolution code will calculate the digest based off the contents of the old asset? I would expect the dependency to be:

file-digest:///home/ops/apps/alpha.example.com/current/app/assets/javascripts/preferences.js

[jeremy]

@wlipa Exactly, yes. This is why @schneems has been converting absolute paths to relative paths.

[wlipa]

I think what may be happening is the line in loader.rb fetch_asset_from_dependency_cache that does an in-place expansion of the dependency paths for preexisting history is not getting undone in the scenario where we fall though to the second half of the function.

deps.map! { |path| path.start_with?("file-digest://") ? expand_from_root(path) : path }

is an in-place modification of the history array of dependencies. There's a line in that second half which does path compression but only on the current asset. There's nothing that undoes the expand_from_root above.

uri.start_with?("file-digest://") ? compress_from_root(uri) : uri

So when the unshift happens, some absolute paths can get into the history cache.

cache.set(key, history.unshift(deps).take(limit))

[jeremy]

Fixed @ #141, #142, #143.