feat(banner): 1Hz poll + cache-bust assets via ?v=buildId - #10
Merged
Conversation
Two coupled changes so the round-duration display stops drifting:
1) poll_interval_ms 4000 -> 1000 in _data/site.yaml. Matches the
serverinfo-updater's now-1s poll cadence (companion infra PR), so
the browser never holds onto a >1s-stale value.
2) Cache-bust JS + CSS via ?v={buildId}. Caddy serves /assets/* with
Cache-Control: max-age=31536000, immutable. CopyWebpackPlugin does
not hash the JS bundles (and the existing webpack output for CSS
doesn't use contenthash either), so without a query-string version
any visitor who ever loaded the page would keep their cached copy
indefinitely. buildId is Date.now().toString(36) computed once at
eleventy startup, so all assets in one build share a buildId and
every npm run build mints a new one.
Drop the local 1Hz ticker and last_update anchoring from
gamebanners.js — at 1Hz polling the interpolation is redundant
(the value updates server-side every second anyway) and the simple
poll model is what was requested.
s950tx16wasr10
added a commit
to ReduxStation/infrastructure
that referenced
this pull request
May 18, 2026
Companion to ReduxStation/website#10 which moves the landing-page poll to 1Hz. Without matching server-side cadence the browser sees the same JSON for 4 fetches in a row and the timer steps 4s at a time. Cost: /world/Topic ?status runs sub-millisecond per call on DD's main thread; 1Hz is ~0.1% of one core. The 700-byte atomic file write hits page cache, not disk per write. The public-log-parser still polls its own 60s cadence.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Two coupled changes so the round-duration display stops drifting:
`poll_interval_ms` 4000 -> 1000 in `_data/site.yaml`. Matches the
serverinfo-updater's now-1s poll cadence (companion PR
`chore(serverinfo): POLL_INTERVAL 4s -> 1s infrastructure#4`), so the browser never holds a
Cache-bust JS + CSS via `?v={buildId}`. Caddy serves `/assets/*`
with `Cache-Control: max-age=31536000, immutable`, but
CopyWebpackPlugin doesn't hash the JS bundles and the existing
webpack output for CSS doesn't use contenthash either. So without
a query-string version, any visitor who ever loaded the page kept
their cached copy indefinitely — which is why the previous
"timer drift fix" looked like it didn't ship.
`buildId` is `Date.now().toString(36)` computed once at eleventy
startup; all assets in one build share a buildId and every
`npm run build` mints a new one.
Also
Drops the local 1Hz ticker and `last_update` anchoring from
`gamebanners.js`. At 1Hz polling on both ends, the interpolation is
redundant (value updates server-side every second anyway) and the
plain poll model is what was requested.
Deploy
After both PRs merge:
```
docker compose build --no-cache website-builder
docker compose up website-builder
```
Existing visitors with the stale-cached JS will pick up the new
bundle on their next page load because the `?v=` querystring on the
`<script>` tag changes the cache key.