Production incident fix. I introduced this bug in #30.
What happened:#30 added rsync --exclude assets/ so old app assets survive a deploy. An unanchored rsync exclude matches every directory named assets, including public/element-call/assets/. From then on, each deploy updated the call page's index.html but never its hashed scripts.
After tonight's lotus.28 deploy, index.html referenced index-CLdjwY1J.js and matrix-DKTWNs45.js, while the server still had the Oct 18 files, so calls failed to load.
Access logs (kept back to Oct 6): 66 × 404 on call assets, from 00:05 on 2026-10-20 until I copied the current build's call assets into place (additive rsync, nothing deleted).
There were no call-asset requests at all on Oct 17–19, so I can't rule out that browsers or the service worker hid it earlier.
All 7 call-page assets now return 200 on both hosts, and the page boots with no failed requests or script errors.
Fix
The excludes are anchored: --exclude /assets/ --exclude /public/element-call/assets/.
Both asset directories get the #23 treatment: copied without --delete, pruned after 14 days. An already-open call page keeps its scripts across a deploy.
config.json stays unanchored on purpose: public/element-call/config.json is the production call config (from Aug 12), and the build's dev copy must not overwrite it.
Tested on a scratch tree with this exact block:
New index.html + scripts deployed for both the app and the call page.
Recent old scripts kept; a 20-day-old one pruned.
Both production config.json files untouched; a stray file deleted.
**Production incident fix.** I introduced this bug in #30.
**What happened:** #30 added `rsync --exclude assets/` so old app assets survive a deploy. An unanchored rsync exclude matches **every** directory named `assets`, including `public/element-call/assets/`. From then on, each deploy updated the call page's `index.html` but never its hashed scripts.
After tonight's lotus.28 deploy, `index.html` referenced `index-CLdjwY1J.js` and `matrix-DKTWNs45.js`, while the server still had the Oct 18 files, so **calls failed to load**.
- Access logs (kept back to Oct 6): **66 × 404 on call assets, from 00:05 on 2026-10-20** until I copied the current build's call assets into place (additive `rsync`, nothing deleted).
- There were no call-asset requests at all on Oct 17–19, so I can't rule out that browsers or the service worker hid it earlier.
- All 7 call-page assets now return 200 on both hosts, and the page boots with no failed requests or script errors.
**Fix**
- The excludes are anchored: `--exclude /assets/ --exclude /public/element-call/assets/`.
- Both asset directories get the #23 treatment: copied without `--delete`, pruned after 14 days. An already-open call page keeps its scripts across a deploy.
- `config.json` stays unanchored on purpose: `public/element-call/config.json` is the production call config (from Aug 12), and the build's dev copy must not overwrite it.
**Tested** on a scratch tree with this exact block:
- New `index.html` + scripts deployed for both the app and the call page.
- Recent old scripts kept; a 20-day-old one pruned.
- Both production `config.json` files untouched; a stray file deleted.
- `bash -n` and shellcheck are clean.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5
#30 added `rsync --exclude assets/` to keep old app assets, but an
unanchored exclude matches every directory named assets, including
public/element-call/assets/. Each deploy then updated the call page's
index.html but not its hashed scripts, so after the lotus.28 deploy the
call page requested files that did not exist (66 x 404 from 00:05 on
2026-10-20 until the assets were copied in by hand).
The excludes are now anchored (/assets/, /public/element-call/assets/), and
both asset directories get the same treatment: copied without --delete,
pruned after 14 days, so an open call page keeps its scripts across a
deploy. config.json stays unanchored on purpose (the production call
config lives at public/element-call/config.json).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5
jared
merged commit 963bc87c54 into main2026-10-20 01:55:38 -04:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Production incident fix. I introduced this bug in #30.
What happened: #30 added
rsync --exclude assets/so old app assets survive a deploy. An unanchored rsync exclude matches every directory namedassets, includingpublic/element-call/assets/. From then on, each deploy updated the call page'sindex.htmlbut never its hashed scripts.After tonight's lotus.28 deploy,
index.htmlreferencedindex-CLdjwY1J.jsandmatrix-DKTWNs45.js, while the server still had the Oct 18 files, so calls failed to load.rsync, nothing deleted).Fix
--exclude /assets/ --exclude /public/element-call/assets/.--delete, pruned after 14 days. An already-open call page keeps its scripts across a deploy.config.jsonstays unanchored on purpose:public/element-call/config.jsonis the production call config (from Aug 12), and the build's dev copy must not overwrite it.Tested on a scratch tree with this exact block:
index.html+ scripts deployed for both the app and the call page.config.jsonfiles untouched; a stray file deleted.bash -nand shellcheck are clean.🤖 Generated with Claude Code
https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5