docs(backup): correct why the sidecar database is not backed up #20

wtclaude · 2026-08-17T18:02:52Z

wtclaude commented

2026-08-17 18:02:52 +00:00

Teams Phase 1, smallest piece. Docs only — no logic change. Targets edge.

Spec: docs/link/v4.md §3.2

backup.rs justifies skipping the sidecar database on two claims. Protocol 4 falsifies one and reveals the other was already wrong.

"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 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 (link #31). A run can change the database's structure, not only its contents.

"Every table holds shard state the sweeps repopulate." events does not. It is never pruned, and module-uo/server/utils/uoLinkSocket.js backfills what the site missed from GET /history on every reconnect. So a lost database costs the gap-recovery window for whatever happened while the site was down — and this 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 it has 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. Flagging it rather than acting on it.

cargo fmt --check clean; cargo test 149 passed.

AI-assisted: written with Claude Code. Commits carry Co-Authored-By: Claude <noreply@anthropic.com>.

Teams **Phase 1**, smallest piece. **Docs only — no logic change.** Targets `edge`. Spec: [`docs/link/v4.md`](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/edge/link/v4.md) §3.2 `backup.rs` justifies skipping the sidecar database on two claims. Protocol 4 falsifies one and reveals the other was already wrong. **"`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 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 (link #31). A run can change the database's *structure*, not only its contents. **"Every table holds shard state the sweeps repopulate."** `events` does not. It is never pruned, and `module-uo/server/utils/uoLinkSocket.js` backfills what the site missed from `GET /history` on **every** reconnect. So a lost database costs the gap-recovery window for whatever happened while the site was down — and this 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 it has 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. Flagging it rather than acting on it. `cargo fmt --check` clean; `cargo test` 149 passed. --- AI-assisted: written with Claude Code. Commits carry `Co-Authored-By: Claude <noreply@anthropic.com>`.

wtclaude added 1 commit 2026-08-17 18:02:54 +00:00

docs(backup): correct why the sidecar database is not backed up

PR Checks / rust-gates (pull_request) Successful in 1m49s

Details

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>

whitlocktech merged commit c3771d22f2 into edge

2026-08-17 19:28:27 +00:00

whitlocktech deleted branch feat/teams-phase1-guild-roster

2026-08-17 19:28:28 +00:00

whitlocktech referenced this issue from a commit

2026-08-17 19:28:29 +00:00

Merge pull request 'docs(backup): correct why the sidecar database is not backed up' (#20) from feat/teams-phase1-guild-roster into edge

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/installer#20