From 2bad147e6e9160d885e87a044ec3f97b796d545c Mon Sep 17 00:00:00 2001 From: "@permadeath.com" Date: Mon, 14 Sep 2026 13:11:35 -0400 Subject: [PATCH] docs(deployment): say that a restore puts subscribeRepos behind A restored volume resumes below the numbers the lost run handed out, so a relay holding a cursor from that run has to be reset rather than resumed; whether a restore should raise the floor instead is the operator's call. Change-Id: I9dccd6066a7b51719881674e17a18d960c2751c1 --- docs/deployment.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/docs/deployment.md b/docs/deployment.md index bff888b6..6cfe70d9 100644 --- a/docs/deployment.md +++ b/docs/deployment.md @@ -512,7 +512,7 @@ investigate old denials must raise the retention before starting the restored server, not after. The write log's segments are trimmed the same way, against `[capacity] write_log_retention_days`. -**A restore does not recover four things, and each fails differently:** +**A restore does not recover five things, and each fails differently:** - **Sessions.** Every access and refresh token is in-process memory. A restore is a restart, so every signed-in client is logged out, and the failure is @@ -534,6 +534,16 @@ way, against `[capacity] write_log_retention_days`. to the issuer's rate limits on a name that has been issued repeatedly. - **Anything written since the snapshot.** Up to twenty-four hours of accounts and records. There is no point-in-time recovery here and no log shipping. +- **The position of `com.atproto.sync.subscribeRepos`.** The restart floor is + whatever the restored log carries, so the stream resumes below the numbers + the lost run handed out and issues those same numbers to different commits. + A relay holding a cursor from the lost run is not told: from the restored + server's side the numbers are new, and its repository heads are behind what + the relay already applied, so the next commit the relay does receive names a + `prev` it does not hold. **Reset every consumer of that stream after a + restore rather than letting it resume.** `/firehose` is not affected — its + cursor names the run that minted it, so a consumer of that one is told + `OutdatedCursor` and reads the repositories for the gap. **The restore drill.** Step 4 is the whole of it: a snapshot that attaches and mounts proves the filesystem, not the log. -- 2.51.2