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)
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.
Assignee | ||
Comment 1•12 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•12 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).
Comment 3•12 years ago
|
||
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.
Comment 4•12 years ago
|
||
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•12 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 (:
Updated•12 years ago
|
Assignee: nobody → thepotch
Assignee | ||
Comment 6•12 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•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Whiteboard: [qa-]
You need to log in
before you can comment on or make changes to this bug.
Description
•