From 5c5b07f565ab2a5d0e66b877d4835e328f801050 Mon Sep 17 00:00:00 2001 From: Bretton Date: Sat, 8 Aug 2026 14:38:31 -0700 Subject: [PATCH] docs(prd): record the comment/vote orphaning gap as a blocking pre-run decision Found in the task-8 re-review: a fully successful cutover run leaves every comment and vote orphaned, because their strongRefs live in user repos and pin both halves of an identity the migration changes. Three options, all needing a decision before the prod run; the ledger mapping must be captured before the truncate either way. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01QDvRJ45k6E5KrBARDHUtiM --- docs/PRD_AUTHOR_OWNED_POSTS.md | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/docs/PRD_AUTHOR_OWNED_POSTS.md b/docs/PRD_AUTHOR_OWNED_POSTS.md index 0a10ea5..ba55058 100644 --- a/docs/PRD_AUTHOR_OWNED_POSTS.md +++ b/docs/PRD_AUTHOR_OWNED_POSTS.md @@ -740,6 +740,34 @@ relaunders a removed post, so the sequence is fixed: states so a crash after checkpoint retries only the delete. 5. **Truncate + firehose re-index `posts`** (§5.1). The tool writes repo records + ledger only; the consumer re-indexes the fresh postv2/acceptance. + + > **BLOCKING — UNRESOLVED (found 2026-08-08, task-8 re-review).** Re-index + > alone leaves **every comment and every vote on every migrated post + > orphaned.** Comments pin `reply.root`/`reply.parent` and votes pin + > `subject` as `strongRef` — URI *and* CID — and re-materialization changes + > both halves of a post's identity (authority community→author, collection + > `post`→`postv2`, new rkey, new CID). Those refs live in **user repos**, so + > the AppView cannot rewrite them, and `comment_consumer` deliberately + > REFUSES an update that changes `root`/`parent` (thread-hijack guard), so + > they cannot be repaired in place. After a fully *successful* run, every + > migrated post renders with **0 comments and 0 score** — the "post husks + > with no comments and no scores" outcome §1.3 opens by naming as the + > problem this design exists to solve. The consumers log + > `Root post not found` / `Vote subject not found` and continue, so nothing + > fails loudly. + > + > Three options, all needing a decision BEFORE the prod run: + > (a) an AppView-side remap that rewrites `comments.root_uri/root_cid`, + > `comments.parent_uri/parent_cid` and `votes.subject_uri/subject_cid` from + > the ledger, with the re-index reading through it — the repo records stay + > stale but the product works; + > (b) re-materialize comments and votes too (cascades: comment URIs change, + > so nested `parent` refs chase them); + > (c) accept the loss explicitly and say so in the release notes. + > + > The ledger holds everything a remap needs (`old_uri`, `new_uri`, + > `new_cid`) — **but only for `done` rows, so the mapping must be captured + > before anyone truncates.** Do not run step 5 until this is settled. 6. **POST-DRAIN FOLLOW-UP (separate branch, gated on `SELECT count(*) FROM posts WHERE split_part(uri,'/',4)='social.coves.community.post'` = 0 AND fallbacks = 0):** only then remove the legacy surfaces — -- 2.51.2