fix(hermit): add TTL to hermit bootstrap file cache#274
fix(hermit): add TTL to hermit bootstrap file cache#274joshfriend wants to merge 1 commit intomainfrom
Conversation
joshfriend
requested review from
alecthomas and
inez
and removed request for
a team
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: df61311fc9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if strings.HasPrefix(base, "hermit-") && strings.HasSuffix(base, ".gz") { | ||
| return true | ||
| } | ||
| return base == "install.sh" || base == "install_hash" |
There was a problem hiding this comment.
isHermitBootstrapFile() matches only on the basename (hermit-*.gz, install.sh, install_hash), but this function is now applied to every direct Hermit proxy request (/hermit/{host}/{path...} via createDirectHandler). That means unrelated package URLs that happen to end with those names will now be forced to a 1-hour TTL, even when their URLs are versioned/immutable and should stay cached long-term. This widens the change beyond Hermit bootstrap artifacts and can materially reduce cache hit rate and reproducibility for non-bootstrap downloads.
Useful? React with 👍 / 👎.
Hermit distribution channels serve the hermit binary and install script at fixed URLs that change content when new versions are released (e.g. hermit-linux-amd64.gz, install.sh). The hermit strategy was caching these indefinitely, which caused hermit to self-downgrade on workstations: 1. Cachew caches hermit-linux-amd64.gz (e.g. v0.50.1) with no expiry 2. A new hermit version is released (e.g. v0.52.1) at the same URL 3. Hermit's self-update checks the ETag via cachew, gets a mismatch 4. Hermit re-downloads the binary through cachew, gets the stale v0.50.1 5. Hermit replaces its own binary with the older cached version This adds a 1-hour TTL to bootstrap files so cachew re-fetches them from the upstream distribution host after expiry. Regular hermit package downloads (which have versioned URLs) are unaffected.
joshfriend
force-pushed
the
jfriend/hermit-bootstrap-ttl
branch
from
df61311 to
d3f6989
Compare
|
i missed that #272 already fixed this 🤦 |
1 participant
Hermit distribution channels serve the hermit binary and install script at fixed URLs that change content when new versions are released (e.g.
hermit-linux-amd64.gz,install.sh). The hermit strategy was caching these indefinitely, which caused hermit to self-downgrade when used with cachew as a download proxy.The self-downgrade happens because hermit has a self-update mechanism (
EnsureChannelIsUpToDate) that checks an ETag on the binary URL. When the upstream releases a new version, the ETag changes, so hermit detects a mismatch and re-downloads the binary. But since cachew serves the old cached binary, hermit replaces itself with the stale version, effectively downgrading.This adds a 1-hour TTL to hermit bootstrap files (
hermit-{os}-{arch}.gz,install.sh,install_hash) in the direct handler. Regular hermit package downloads have versioned URLs and are unaffected. Public hermit (GitHub releases) goes through the redirect handler which already usesNoOpCachefor internal redirects, so this only affects non-GitHub distribution hosts.