Commit Graph

1 Commits

Author SHA1 Message Date
type-two
1233a9effe [lane F] The stale-edge fix, prepared but not applied
The step-5 check added in the previous commit failed on its first real deploy, and it was
right: cf-cache-status HIT, age 158, cache-control max-age=14400, and the edge serving the
PREVIOUS boot.js. forum-nginx sends no Cache-Control for /gutsy/ at all, so Cloudflare applies
its 4-hour default to a game that ships un-versioned ES modules with no build step — what the
edge holds is code, not assets.

tools/forum-nginx-default.conf is the container's config with a /gutsy/ block adding
Cache-Control: no-cache (store, but revalidate — the files are etag'd, so it costs a 304).
Scoped to /gutsy/; nothing else on partly.party is touched. tools/CACHE.md has the measurement
and the two commands.

NOT APPLIED. Copying a file into the live forum-nginx container is gated for me, which is the
right gate on shared infrastructure hosting partly.party — I have not tried to route around it.
Until John runs it, a deploy reaches players when the 4-hour TTL lapses or the cache is purged.
The container has no bind mount for that config, so a force-recreate wipes the block; the file
is in the repo so re-applying is the same two commands.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-26 22:35:05 +10:00