docs(operations): require a landed upstream fix before deleting the forensic volume

[Fl0p]

The retention rule in docs/operations/duckdb-recovery.md released the forensic volume cotel_cotel-data when upstream duckdb#25360 "is resolved". Two problems, both measured today:

• The issue is not ours: filed by an unaffiliated reporter (author_association: NONE) against a ~19 GB database. A maintainer asked that reporter for a minimal reproducer on 2026-10-07 and has had no answer in six days, so the likely end state is a close as stale - which satisfies "is resolved" while the defect is still live, and would authorise deleting the only artifact in existence that reproduces it.
• The second half of the condition ("cotel no longer links a DuckDB that can hit it") is unevaluable, not satisfied: cotel links duckdb-go/v2 v2.10506.0 (DuckDB 1.5.6), the crash was on 1.1.3, and nobody has demonstrated either way.

The rule now asks for a landed fix (read the closing commit, not the state) and says the version half is open.

Also in this change:

• Records the mechanism match rather than leaving it symptomatic: the upstream trigger is ALTER TABLE adding a VARCHAR column to a long-lived indexed table plus a large replace transaction, and internal/storage/schema.sql:53,74 adds spans.user_id VARCHAR and then indexes that same added column.
• Bans attaching the volume, or anything extracted from it, to a public upstream issue - it is production telemetry (user ids, session ids, span attributes). Any upstream contribution has to be a synthetic reproducer, and publishing one is an external-facing decision.
• Marks the step-2 copy from the 2026-10-04 recovery as deleted on 2026-10-13, so the classification walkthrough matches what docker volume ls now shows (three volumes, not four).

Verification

• npm run build in docs/ green (VitePress fails the build on broken links).
• Deletion was hash-verified before it ran: both cotel_cotel-data and cotel-data-backup-20261004 returned 7eb82bbe… / 33e13061…, and the backup was mounted by no container. After the delete the original still returns 7eb82bbe…; prod ok:true, 74927 spans, restarts=0, snapshot worker ok.
• Upstream state re-read today: open, one maintainer comment 2026-10-07, no state_reason.

Docs-only, no behaviour change.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 55 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

• Configuration used: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: bf7d547b-bb2b-495c-9909-ccb2722df2f5

📥 Commits

Reviewing files that changed from the base of the PR and between c43e41c and 8672e45.

📒 Files selected for processing (1)

• docs/operations/duckdb-recovery.md

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}