docs(backup): correct why the sidecar database is not backed up (Teams cutover 3/6) #21

Merged
whitlocktech merged 2 commits from edge into main 2026-08-19 08:56:12 +00:00
Member

Cutover 3 of 6, and the smallest of them: one docstring, no behaviour change.

backup.rs justified not copying the sidecar database on two claims, and protocol 4 falsifies one of them:

  • "every table is CREATE TABLE IF NOT EXISTS" — no longer true. link grew PRAGMA user_version stepped migrations for guilds.members (RunicGateway/link#32, cutover 2/6).
  • "the sweeps repopulate everything" — already false before this: events is never pruned, and the website backfills from GET /history on every reconnect.

The behaviour is unchanged and still correct. Only its stated reason needed fixing — a wrong reason left in place is what lets someone extend it to a case it never covered.

Merge after cutover 1 and 2, since it describes a sidecar that exists once those land. Note that releases are cut from main on every push here.

AI disclosure

Written with Claude Code (Opus 5). Commits carry the Co-Authored-By trailer.

**Cutover 3 of 6**, and the smallest of them: one docstring, no behaviour change. `backup.rs` justified not copying the sidecar database on two claims, and protocol 4 falsifies one of them: - *"every table is `CREATE TABLE IF NOT EXISTS`"* — no longer true. `link` grew `PRAGMA user_version` stepped migrations for `guilds.members` (`RunicGateway/link#32`, cutover 2/6). - *"the sweeps repopulate everything"* — already false before this: `events` is never pruned, and the website backfills from `GET /history` on every reconnect. **The behaviour is unchanged and still correct.** Only its stated reason needed fixing — a wrong reason left in place is what lets someone extend it to a case it never covered. **Merge after cutover 1 and 2**, since it describes a sidecar that exists once those land. Note that releases are cut from `main` on every push here. ### AI disclosure Written with Claude Code (Opus 5). Commits carry the `Co-Authored-By` trailer.
wtclaude added 2 commits 2026-08-19 08:53:04 +00:00
docs(backup): correct why the sidecar database is not backed up
All checks were successful
PR Checks / rust-gates (pull_request) Successful in 1m49s
6c49217e9c
backup.rs justified skipping the sidecar's database on two claims. Protocol 4
falsifies one and reveals the other was already wrong.

It said the database is safe because store.rs creates every table IF NOT EXISTS.
That held only while every schema change added a whole table — which, up to and
including Protocol 3.0, every one of them did. Protocol 4 adds a COLUMN to a table
that already exists, which IF NOT EXISTS cannot do, so link now carries a real
migration. A run can change the database's structure, not only its contents.

It also said every table holds state the sweeps repopulate. `events` does not: it
is never pruned, and the website backfills what it missed from GET /history on
every reconnect. So a lost database costs the gap-recovery window for whatever
happened while the site was down. That claim was untrue before this workstream
existed.

The behaviour does not change — the database is still not copied — because the
argument against backing up unbounded bulk survives both corrections: `events`
grows without limit, the migration is transactional and additive, and the website
holds its own durable copy of everything already ingested. Only the reasoning was
wrong, and a wrong reason left in place is what lets the next person extend it to
a case it never covered.

Whether that unbounded table should be pruned or protected belongs to link, on its
own merits, rather than being settled inside a backup policy.

No logic change; docs only.

Refs: docs/website/TEAMS.md Part 12 Phase 1

Co-Authored-By: Claude <noreply@anthropic.com>
Reviewed-on: #20
whitlocktech approved these changes 2026-08-19 08:55:59 +00:00
whitlocktech scheduled this pull request to auto merge when all checks succeed 2026-08-19 08:56:04 +00:00
whitlocktech merged commit 5d4c68eaf5 into main 2026-08-19 08:56:12 +00:00
Sign in to join this conversation.
No description provided.