Update cache control settings for release manifests and downloads

[DTTerastar]

Summary by CodeRabbit

• Bug Fixes
  • Optimized cache control for release downloads and manifests, implementing improved cache durations to ensure faster delivery of the latest releases while maintaining efficiency for specific version releases.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

This PR refactors the caching strategy in the release proxy by removing middleware-based cache control and implementing explicit per-route Cache-Control headers. Routes now compute maxAge based on whether they serve latest releases (300 seconds) or specific versions (86400 seconds), setting the appropriate header on each response.

Changes

Cohort / File(s)	Summary
Cache Control Refactoring espresense-release-proxy/src/index.ts	Removed hono/cache middleware import. Added explicit per-route cache control logic to three endpoints: manifest retrieval, release downloads, and latest-any downloads. Each route now conditionally computes maxAge (300s for latest, 86400s for versioned) and sets the Cache-Control header directly on responses.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Possibly related PRs

• Set Cache-Control header on asset download redirect #4 — Modifies the same /latest-any/download/:filename redirect endpoint with explicit Cache-Control headers; this PR changes the cache duration from 3600s to 300s.

Poem

🐰 No more middleware chains, just headers clean and bright,
Hop from latest to the vault, each route knows what's right—
Latest? Five quick minutes! Versions? A full day's delight,
Cache control now local, the proxy's feeling light! ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: replacing middleware-based caching with per-route cache control logic that sets Cache-Control headers based on release type (latest vs specific).

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch cache

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

espresense-release-proxy/src/index.ts (1)

80-82: Consider extracting the maxAge logic into a helper function.

The maxAge calculation is duplicated in both the manifest and download endpoints. You could extract this into a reusable helper to improve maintainability:

🔎 Optional refactor suggestion

+function getCacheMaxAge(tag: string): number {
+  // latest changes frequently, specific releases are immutable
+  return tag === 'latest' ? 300 : 86400
+}
+
 function esp32(path: string) {

Then use it in both routes:

-    // latest changes frequently, specific releases are immutable
-    const maxAge = tag === 'latest' ? 300 : 86400
+    const maxAge = getCacheMaxAge(tag)

Also applies to: 119-121

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 38b8011 and acb8913.

📒 Files selected for processing (1)

• espresense-release-proxy/src/index.ts

🔇 Additional comments (3)

espresense-release-proxy/src/index.ts (3)

119-121: Same cache TTL mismatch as in the manifest endpoint.

Similar to the manifest endpoint, the client-side Cache-Control allows specific release downloads to be cached for 1 day, while the Cloudflare edge cache (cacheTtlByStatus on line 125) revalidates every 5 minutes.

Consider aligning the edge cache TTL with the client cache for specific releases if immutability is guaranteed.

Also applies to: 125-125

---

140-172: LGTM! Consistent caching for latest prerelease.

The caching strategy for the latest prerelease endpoint is consistent, with both client-side and edge cache set to 5 minutes (300s). The explicit Cache-Control header on the redirect response ensures proper cache behavior.

---

80-82: Confirm the cache strategy for specific releases between client and edge caches.

The client-side Cache-Control header allows specific releases to be cached for 1 day (86400s), but the Cloudflare edge cache (cacheTtlByStatus on lines 86, 125, and 148) is set to 300s for all responses. This means specific release manifests and downloads cache for 1 day on clients but revalidate on the edge every 5 minutes—inconsistent with the immutability stated in the code comments.

If immutable releases should be cached longer on the edge, consider raising cacheTtlByStatus to 86400 for non-latest tags. If the current setup is intentional (keeping the edge cache fresh), document the reasoning. Additionally, the maxAge computation is duplicated across endpoints (lines 81 and 120); consider extracting it to reduce duplication.