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

RESOLVED FIXED in 2012-10-18

Status

Marketplace
General
P2
normal
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: cvan, Assigned: potch)

Tracking

2012-10-18
Points:
---

Details

(Whiteboard: [qa-])

(Reporter)

Description

6 years ago
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.
(Assignee)

Comment 1

6 years ago
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.
(Assignee)

Comment 2

6 years ago
* 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?
(Reporter)

Comment 5

6 years ago
(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
(Assignee)

Comment 6

6 years ago
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
(Assignee)

Updated

6 years ago
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.