Make sure that Metabase JS/CSS isn't cached by browser

[agilliland]

Seen a couple reports of cases where the app was updated and the index.html page served by the metabase frontend had changed, but the user's browser was continuing to use an older version of the page until a hard page refresh was done.

[camsaul]

A normal refresh didn't do it?

[agilliland]

nope. had to be a hard refresh.

[camsaul]

Here's the headers that come back with index.html. Something must be off here

Also, what browser were you using?

[tlrobinson]

FWIW we don't actually know if it was the index.html or the js/css that was being cached, do we? In theory we have a cache busting set up for anything loaded by webpack, but it's possible it's not working.

[agilliland]

Correct. I filed this because we saw a user run into this problem and a refresh was the solution, but we don't know the exact cause.

[agilliland]

Just a quick update that we've had several other people report running into this issue on the latest 0.16.0 release candidate, so it's definitely happening. Here's a screenshot of the problem in action on the QB ...

[camsaul]

I think @tlrobinson is right about the JS / CSS being the issue here. The cache-busting headers are only added to index.html and API calls.

app.bundle.js

relevant code:

(defn add-security-headers
  "Add HTTP headers to tell browsers not to cache API responses."
  [handler]
  (fn [request]
    (let [response (handler request)]
      (update response :headers merge (cond
                                        (api-call? request) (api-security-headers)
                                        (index? request)    (index-page-security-headers))))))

[agilliland]

The cache busting for the JS/CSS should be happening due to the fact that we append a randomized hash on those urls right?

In any case, given that we've seen several folks run into this since deploying 0.16.0 can we address this somehow before the release goes out?

[tlrobinson]

@agilliland correct, JS and CSS files should be aggressively cached, then "cache busted" by changing the hash in the query string when re-built. AFAIK Webpack is doing this correctly, so I'm pretty stumped why this is happening. I'll keep poking at it.

[camsaul]

I don't think the randomized hash is working correctly. I'm looking at the network inspector and when I soft reload a page it fetches vendor.bundle.js with the exact same hash as the last time.

[camsaul]

Why can't we just add cache-prevention headers to the JS and CSS files and skip this random hash stuff?

[tlrobinson]

Because we have like 2MB of JS/CSS that we don't want to reload every time unless it actually changes. This is a pretty common practice.

[tlrobinson]

Ok so I'm pretty sure I figured it out... it wasn't index.html, css, or js being cached, it was...

One of the last few Angular HTML partials, hooray!

Changing the headers for partials won't fix this for people who already have the partial cached. A couple options:

1. Easier: manually add a cache-busting query string here: https://github.com/metabase/metabase/blob/master/frontend/src/card/card.module.js#L13
2. Better: set up partials to be loaded through Webpack's file-loader (doesn't bundle them, but can do cache busting I think)

[agilliland]

I'm fine with taking the easy approach here and calling it done. The real fix can come when we move this stuff over to redux and don't have any other external templates to load.