Problem
When you visit https://element-hq.github.io/synapse/latest/welcome_and_overview.html, the version picker can be stuck with only older Synapse versions available. This is because we configure force-cache to tell the browser to use a cached response if available regardless of if it's stale or not,
|
fetch("https://api.github.com/repos/element-hq/synapse/git/trees/gh-pages", { |
|
cache: "force-cache", |
force-cache — The browser looks for a matching request in its HTTP cache. If there is a match, fresh or stale, it will be returned from the cache.
-- https://developer.mozilla.org/en-US/docs/Web/API/Request/cache
I noticed this because I'm driving the release process and wanted to link some docs for the changelog but I couldn't see the new version on the docs site. Turned out that the new version of the docs was available (CI runs for release-v*, develop, and master) and its only the version picker that is stale.
Potential solutions
We can't really rely on the cache headers from https://api.github.com/repos/element-hq/synapse/git/trees/gh-pages either as it only has cache-control: public, max-age=60, s-maxage=60 (valid for 60 seconds) and the GitHub API only allows 60 API requests per hour when unauthenticated. It's technically just enough to cover us but it's totally unnecessary to spam the GitHub API every minute and we should be respectful that other things on their machine might also want to use the GitHub API.
The fetch API doesn't seem to have a way to force-cache but only up to some expiry time.
We could add ?cache-bust=xxx parameter with a timestamp rounded to the nearest hour/day. This would cause us to only make a new request every hour/day.
Other solutions like storing it with service worker, local storage, etc are pretty heavy-weight and probably not worth the complexity.
Problem
When you visit https://element-hq.github.io/synapse/latest/welcome_and_overview.html, the version picker can be stuck with only older Synapse versions available. This is because we configure
force-cacheto tell the browser to use a cached response if available regardless of if it's stale or not,synapse/docs/website_files/version-picker.js
Lines 57 to 58 in 0512511
I noticed this because I'm driving the release process and wanted to link some docs for the changelog but I couldn't see the new version on the docs site. Turned out that the new version of the docs was available (CI runs for
release-v*,develop, andmaster) and its only the version picker that is stale.Potential solutions
We can't really rely on the cache headers from
https://api.github.com/repos/element-hq/synapse/git/trees/gh-pageseither as it only hascache-control: public, max-age=60, s-maxage=60(valid for 60 seconds) and the GitHub API only allows 60 API requests per hour when unauthenticated. It's technically just enough to cover us but it's totally unnecessary to spam the GitHub API every minute and we should be respectful that other things on their machine might also want to use the GitHub API.The
fetchAPI doesn't seem to have a way toforce-cachebut only up to some expiry time.We could add
?cache-bust=xxxparameter with a timestamp rounded to the nearest hour/day. This would cause us to only make a new request every hour/day.Other solutions like storing it with service worker, local storage, etc are pretty heavy-weight and probably not worth the complexity.