Old assets served after deploying an upgrade

Phoenix Forum Questions / Help
, ,
1

I’m not sure if this is an edeliver issue or Phoenix, maybe someone can point me in the right direction and I’ll report the issue - unless of course I’m missing something in my config.

The problem I’ve been facing is that after deploying an upgrade with edeliver the old static assets are served rather than the new ones.

It appears that Phoenix is reading the wrong cache_manifest.json which means that in app.html.eex the script tag

<script defer type="text/javascript" src='<%= Routes.static_path(@conn, "/js/app.js") %>'></script>

is pointing to the original digested js file and becomes:

<script defer type="text/javascript" src="/js/app-[old-hash].js"></script>

rather than

<script defer type="text/javascript" src="/js/app-[new-hash].js"></script>

So the problem appears to be with Routes.static_path/2, although I’m guessing it goes deeper than that.

My current workaround is to add the following to my edeliver config:


post_upgrade_release() {
  # Ref https://github.com/edeliver/edeliver/issues/328
  # Necessary to pick up the correct version after a restart
  status "Updating start_erl.data to version $VERSION if it exists"
  __remote "
    [ -f ~/.profile ] && source ~/.profile
    cd $DELIVER_TO/$APP/var $SILENCE
    sed -i -E \"s/\s[0-9]+\.[0-9]+\.[0-9]+/ $VERSION/g\" start_erl.data &> /dev/null
  "

  # Fix cache_manifest.json
  # Currently Phoenix reads the version in the original release dir after an upgrade
  # so replace it with the new one
  __remote "
    cd $DELIVER_TO/$APP/lib $SILENCE
    cp $APP-$VERSION/priv/static/cache_manifest.json $APP-0.1.0/priv/static/.
  "
}

This replaces the cache_manifest.json in the original release dir with the new one. However, I still have to restart the server in order for the corrected cache_manifest.json file to get picked up, (which defeats the point of the hot code upgrade).

Ideas/suggestions?

Phoenix 1.5.4
edeliver 1.8

TIA

1 Like