Closed Bug 800506 Opened 12 years ago Closed 12 years ago

Fragment-loaded pages are stuck with stale header and CSS/JS after deploys

Categories

(Marketplace Graveyard :: General, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED
2012-10-18

People

(Reporter: cvan, Assigned: potch)

Details

(Whiteboard: [qa-])

This is a problem every time we push -dev and every time we push to production. The inner HTML fragment is new but the header and the CSS+JS are from an old version.

When there is a new push, we need a way to say force a synchronous reload to get new assets.

Krupa also says we need a way to detect when content changes (new apps featured on homepage) and flush the homepage fragment cache/force a new synchronous page load.

This is likely to be a huge problem as we launch publicly.
This is a problem that is not going to get easier, I'm afraid. If we start using offline cache, the cached media will only get update to the new version if *every* single media file is done downloading. That means if there's a network issue, it may be a while before the user has markup in sync with JS.

We should take a few approaches here:
* Find a way to signal an update, and *attempt* to to update our media (if offline is working successfully, this will be mostly done for us!)
* _Never_ assume elements are on the page. (especially for new elements). Our JS will need to be more robust and fail gracefully when content it expects is missing.
* For pages with rotating content (homepage), we should load from the cache, and then attempt to fetch new data and update it. Think an email or twitter client.
* lastly, our fragment cache should have some form of expiry, so we're attempting to fetch new fragments if they are beyond a certain age (a day, for example).
Could you potentially use the media build hash as part of the key you're caching with? e.g. `key = href + build_id` and `if (fragmentCache[key]) ...`. I sure there's a lot more to it than that, though.
1) Is there a reliable workaround for this?  (Jason flushes the cache on our push or something?)

2) What is the ETA to fix?

3) Who is the best person to fix?
(In reply to Wil Clouser [:clouserw] from comment #4)
> 1) Is there a reliable workaround for this?  (Jason flushes the cache on our
> push or something?)

IMO the quickest fix here is to send down a hash of say all the BUILD_IDs with each fragment response and then forcing a synchronous page reload when the hash stored on the client is different.

> 2) What is the ETA to fix?

Can't imagine this taking more than a few hours.

> 3) Who is the best person to fix?

Potch with absolutely certainty (:
Assignee: nobody → thepotch
Now, if we see a fragment returned with a mismatched media hash (made by concatting the JS and CSS minification hashes), the next request will be synchronous.

https://github.com/mozilla/zamboni/commit/4e570b6
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.