feat(recovery): compose isolated logical restore drill

[seonghobae]

ACTIVE Draft — isolated logical recovery drill

This branch composes the bounded logical-recovery acceptance path and remains an explicit child of dependency root #233. Protected main is not written directly.

Current exact stack — 2026-09-11

• protected main: 5913c4bad79d6bc29d7cc1c624abb7db2ea6a77c;
• direct predecessor/base test(recovery): cover stale evidence registry cleanup #233: 01d231fde23b82e2ced258d7bfcb4721ed75706d;
• head branch: feat/logical-recovery-drill-b84f0c9;
• exact current head: 69b2615726b4e8e6657a844b7e15d1a346b4b1d7;
• compare from exact test(recovery): cover stale evidence registry cleanup #233: 10 ahead / 0 behind, merge base exactly test(recovery): cover stale evidence registry cleanup #233;
• effective relative delta is exactly:
  • pg_llm_batch/postgres_logical_recovery_drill.py;
  • tests/test_postgres_logical_recovery_drill.py;
  • tests/test_postgres_logical_recovery_drill_identity_authority.py;
• state: Draft/open/mechanically mergeable;
• fresh formal reviews: none;
• fresh inline review threads: none.

The prior body still described historical protected/base/head identities. Current 69b2615... is already the ordinary, non-force current-root reconciliation (chore(pr234): restack logical recovery drill on current recovery root). Its history adopts #233's current CI/Release Acceptance concurrency contract, removes the retired repository-local hourly-maintenance workflow, and preserves the drill's effective PR delta at the three owned files above. No force push, destructive rebase, protected-main write, self-approval, or gate weakening is used.

Bounded contract

The drill composes recovery-receipt/schema/artifact verification, restore-target isolation, bounded logical restore, archive re-verification, and protected catalog/RLS acceptance. Successful output is content-free evidence for that one logical drill only when every invoked primitive satisfies its own authority contract.

It does not implement physical base backup, WAL archiving/replay, PITR execution, target lifecycle/destruction, application-level readiness, external Fernet/TLS/provider credential recovery, deployment RPO/RTO/HA/DR, or distributed exactly-once semantics. Caller-owned connections, libpq services, trusted-source decisions, credential/key custody, and target teardown remain caller/host authority.

Logical-restore dependency

The invoked logical-restore primitive remains separately owned by Draft #284. Current #284 is exact 075b786a71046ac1b3ab7b1ac90f8c1cd620235b, direct child of exact #233, with a seven-file logical-restore source/test delta. Its archive/executable authority repairs are branch-candidate truth only until normal protected integration. This drill must not duplicate #284 source or treat its branch evidence as protected authority.

Exact-head validation

For exact 69b2615726b4e8e6657a844b7e15d1a346b4b1d7:

• CI 33893880169: completed / success;
• Release Acceptance 33893880105: completed / success;
• fresh formal reviews: none;
• fresh inline review threads: none.

These successes prove this exact branch head only. They are not independent approval, protected-main evidence, or immutable-release authority.

Integration boundary

#233 must integrate first through then-live governance, followed by the separately owned logical-restore primitive required by this composition. Mutable central workflow/review state remains tracked in #244 rather than frozen into this PR body.

After prerequisites reach protected main, reconcile this three-file child non-destructively onto the resulting protected ancestry, re-prove the composition contract, and reacquire every then-required exact-final-head/current-base quality, supported-Python, exact owned production coverage/docstring, security/SAST, package/SBOM/provenance/release, formal-review, and unresolved-thread gate. Queued, pending, cancelled, skipped-required, absent, stale, predecessor, status-only, synthetic, author-only, or infrastructure-failed evidence is non-passing.

Refs #204, #233, #244, #254, #284, #286, #287.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

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.}

[seonghobae]

Fresh exact-head audit on 1ff6fab0032956d0aca25c815929296a6264ee4f found an evidence-provenance gap that should remain Draft-blocking until either the implementation or the evidence contract is narrowed.

run_postgres_logical_recovery_drill() currently accepts three separately caller-controlled authorities: restore_service_name (used by pg_restore), restore_target_identity (used by the isolation check and copied into restore_system_identifier), and restore_connection (used for post-restore catalog/RLS inspection). verify_postgres_restore_target_isolation() only proves that the supplied names and supplied identity values differ from the live values; it does not prove that the supplied restore_target_identity.system_identifier was observed through restore_connection, nor that restore_connection is the cluster actually reached by restore_service_name.

The success path then emits restore_system_identifier=restore_target_identity.system_identifier. A caller can therefore supply identity A, restore through service B, inspect catalog through connection C, and receive evidence attributing the accepted drill to A as long as the independent lower-layer calls succeed. Existing tests mock these authorities independently and do not exercise this mismatch.

This is an evidence/data-integrity boundary, not a claim that caller-owned connections/services are forbidden. Smallest defensible repair should be test-first: add a RED where the post-restore connection reports a system identifier different from the supplied restore identity and prove the drill fails closed before emitting evidence. Then either (a) bind the emitted identifier to an exact pg_control_system() observation through the same restore connection used for catalog acceptance, with bounded/content-free failure behavior, while retaining an explicit non-guarantee that the libpq service-to-connection binding remains caller/host authority; or (b) if that same-connection observation is intentionally outside package authority, stop emitting/wording restore_system_identifier as observed drill evidence and mark it explicitly caller-asserted. Do not widen this PR into physical PITR or duplicate #233's unrelated aggregate-coverage repair.