Skip to content

feat(recovery): bind inspected WAL segment evidence - #240

Draft
seonghobae wants to merge 19 commits into
fix/recovery-evidence-weakref-coverage-b84f0c9from
feat/postgres-wal-segment-evidence-b84f0c9
Draft

feat(recovery): bind inspected WAL segment evidence#240
seonghobae wants to merge 19 commits into
fix/recovery-evidence-weakref-coverage-b84f0c9from
feat/postgres-wal-segment-evidence-b84f0c9

Conversation

@seonghobae

@seonghobae seonghobae commented Aug 17, 2026

Copy link
Copy Markdown
Contributor

Bounded WAL-byte evidence slice — ACTIVE DRAFT / EXPLICIT #233 CHILD

Bind one canonical PostgreSQL WAL segment filename and reviewed segment size to exact protected stable-file inspection evidence. The slice reuses inspect_postgres_backup_artifact() provenance rather than duplicating descriptor/symlink/mutation-safe hashing, validates PostgreSQL segment-name geometry for the configured size, requires exact inspected byte-count agreement, and keeps the live inspected evidence object attached so copied digest/size fields cannot silently become authority.

It deliberately does not parse WAL headers or records, establish cluster identity or timeline ancestry, prove replayability/PITR/RPO/RTO, or execute recovery. Those remain separate evidence/execution domains under #204.

Exact current stack

  • protected main: c1b41ad9205e41705466c67b83272f3f4d667674
  • base branch: fix/recovery-evidence-weakref-coverage-b84f0c9
  • exact base SHA: 04a6e2450a6df4bff34c797e1828b43fe73a6bf6
  • head branch: feat/postgres-wal-segment-evidence-b84f0c9
  • exact head SHA: d3590436526f1067b0ead239b705c4480ca8d210
  • relative changed surface remains exactly:
    • pg_llm_batch/postgres_wal_segment_evidence.py
    • tests/test_postgres_wal_segment_evidence.py
    • tests/test_postgres_wal_segment_serialization_guard.py

Protected main advanced through #329 while this Draft was open. Fresh compare against current #233 showed the old head diverged only because it lacked the two base-lineage commits; its unique semantic diff remained exactly the three WAL-evidence paths above. Merge commit d3590436526f1067b0ead239b705c4480ca8d210 therefore reconstructs the child non-destructively from current #233 plus those exact three blobs. No force push, destructive rebase, protected-main write, or predecessor evidence transfer occurred.

RED → GREEN lineage

The retained history includes the initial missing-module RED, reserved bootstrap-segment rejection, serialization/provenance TOCTOU RED/GREEN repairs, exact primitive snapshotting across provenance validation, and hostile/non-primitive authority coverage. Current production still requires one canonical uppercase 24-hex WAL segment name on a nonzero timeline, excludes PostgreSQL's bootstrap-skipped first possible segment, requires a reviewed PostgreSQL-supported power-of-two WAL segment size from 1 MiB through 1 GiB, enforces segment-number geometry for that configured size, and requires exact live PostgresBackupArtifactEvidence whose observed byte count matches the segment size.

Both binding creation and postgres_wal_segment_binding_is_valid(...) use primitive snapshots across the provenance decision and reject authority changed inside that validation window. as_dict() fails closed rather than emitting a tampered binding. This remains byte/provenance evidence only: no WAL-header identity, timeline ancestry, replay, PITR, or deployment recovery-objective guarantee follows.

Exact-current validation boundary

Fresh workflow inventory for exact d3590436526f1067b0ead239b705c4480ca8d210 currently contains CI 33711248392 and Release Acceptance 33711248609, both queued and therefore non-passing. All checks/reviews tied to df88b897... or earlier heads are historical after the restack. Fresh formal review/inline-thread state must be reacquired on this exact head before any Ready/merge decision; absence of review is not approval.

Integration boundary

#233 remains the exact predecessor and must integrate through then-live governance first. After that integration, reconcile this Draft to the resulting protected main and reacquire every exact-final-head/current-base CI/security/coverage/docstrings/package/SBOM/provenance/release/review/thread gate. No self-approval, routine bypass, predecessor evidence, force push, or destructive rebase is accepted.

Refs #204, #233, #244 and central .github#712 / .github#772.

@coderabbitai

coderabbitai Bot commented Aug 17, 2026

Copy link
Copy Markdown

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

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

@coderabbitai

coderabbitai Bot commented Aug 17, 2026

Copy link
Copy Markdown

Caution

CodeRabbit couldn't update its existing comment. The review summary may be out of date.

Error details
No server is currently available to service your request. Sorry about that. Please try resubmitting your request and contact us if the problem persists.

@seonghobae
seonghobae changed the base branch from main to fix/recovery-evidence-weakref-coverage-b84f0c9 August 19, 2026 05:04
@opencode-agent opencode-agent Bot added priority: medium Normal-priority or P2 work scope: research Research, statistical validation, or scientific evidence status: draft Draft pull request type: feature New or expanded product capability labels Aug 22, 2026
@seonghobae seonghobae added the enhancement New feature or request label Sep 7, 2026 — with ChatGPT Codex Connector
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request priority: medium Normal-priority or P2 work scope: research Research, statistical validation, or scientific evidence status: draft Draft pull request type: feature New or expanded product capability

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant