Phoenix: Static CSS stuck in cache

[travmichwill]

Problem:

New phoenix project with out brunch is having a hard time updating the served css file to the web browser.

How to recreate:

If I were to update the /priv/static/css/app.css, the original css will stay the same.(almost, see below)

The original css from the new project was greater than 92,000 characters. If the new modified CSS was only 100 characters, then only 100 of the first 92,000 characters will be sent to the browser.

Smaller example: Remove all of the original css and paste the code below, then refresh the url.
New css:

body {
    background-color: #cc00cc;
}

CSS when served to the browser:

/*!
 * Bootstrap v3.1.1 (http://getbo

Note the above examples are both 37 characters long. Below is the work around I found.

Workaround:

1. update css
2. rename /priv/static/css/app.css
3. refresh page so that the "/css/app.css" file is missing
4. rename the file back to app.css
5. refresh page again to see the new file
   

   Versions

Erlang/OTP 18 [erts-7.0] [source] [64-bit] [async-threads:10] [kernel-poll:false]
Interactive Elixir (1.0.5) - press Ctrl+C to exit (type h() ENTER for help)
Phoenix v0.17.0

[josevalim]

You are using old Phoenix and Elixir versions. Can you bump to Elixir 1.1
and at least Phoenix 1.0?

_José Valim_
www.plataformatec.com.br
Skype: jv.ptec
Founder and Director of R&D

[travmichwill]

I have tried the same steps using the updated versions:

Erlang/OTP 18 [erts-7.1] [source] [64-bit] [async-threads:10] [kernel-poll:false]
Interactive Elixir (1.1.1) - press Ctrl+C to exit (type h() ENTER for help)
Phoenix v1.1.0

Same issue appears to happen. At least there is a temporary work around by renaming the file, request the file, and renaming it back. That must be clearing some sort of cache. Let me know if there is anything I can provide!

[chrismccord]

Does this happen in all environments?

[travmichwill]

For what it is worth, I am using Ubuntu 14.4 inside of a vagrant vm, I have not tried from another system yet. I'll give Windows a shot and see what happens.

[chrismccord]

I mean MIX_ENV environments i.e. does it happen in dev and prod the same? But since you mentioned VM, is the vagrant vm sharing disk with the host where the app code lives? This sound like an issue with shared volumes and ctimes. If you do have a shared volume, can you move the codebase to within the VM and see if the problem still exists?

[travmichwill]

Thank you chris! You are correct, once I moved the project to another directory that was not shared, the css was applied instantly. I'm not sure if you want me to keep this open as an issue, but I am happy with the outcome.

[chrismccord]

Glad we got it sorted out! I don't think there's anything to handle on our end in this case.

[sillypog]

I would love to know the cause of this issue. I am running my asset build pipeline in a Docker container and am seeing this same issue - the browser will not load the newly built css file.

I understand that the underlying issue is caused by creating the file in a shared volume of the VM. But I can't find where in the framework this caching behavior arises.

Hopefully this won't be an issue when running on Docker for Mac, but I am not able to use that yet. In the meantime any pointers would be appreciated.

[jeisenberg]

I would also like to know the issue. I am currently using a Docker and docker-compose pipeline that uses a shared volume. This is so our gulp processes can auto-update in the docker container. Any ideas?

[paragasu]

I am facing the same issue. To reproduce the problem, do

1. rm priv/static/css/app.css
2. restart phoenix

Running brunch build will restore the css files but the since the link referred in the html is a different
name like app-afa72a40e480372d80d6fc4592f04e47.css?vsn=d & not being regenerated. Then it return 404 file not found error.

How do i regenerate app-afa72a40e480372d80d6fc4592f04e47.css?vsn=d file?

Some update, i manage to find out the solution,

1. brunch build
2. mix phoenix.digest

[josevalim]

Make sure to run mix phoenix.digest so we can rebuild asset files.

[crertel-packlane]

Just adding a +1 since this issue still occurs, on vagrant with an NFS shared volume. :(

FWIW brunch in watch mode (with polling) picks up on the changes--this seems like a pure asset-pipeline problem on Phoenix's side.

[jayjun]

For Nanobox + macOS (Sierra and above) users, stale compiled assets can be caused by the host file watcher hitting the OS limit (largely due to files under node_modules).

Setting a higher limit fixes it. Add limit.maxfiles.plist and reboot as instructed here.

[chrismccord]

Since we haven't had movement on this in some time, closing until we have more information to work from. With respect tot he shared volume issues, we also include a new file watcher in dev for live reloading that may resolve the issues. If folks run into this in the future please be sure to open an issue with version and environment information. Thanks!