feat(streaming): rebuild resumable checkpoints on current main

[seonghobae]

Current implementation for resumable result checkpoints

This Draft rebuilds the former resumable-checkpoint semantics on the protected streaming result without transferring stale ancestry, checks, reviews, approvals, or generated-merge evidence.

The branch implements immutable BatchResultCheckpoint / CheckpointedBatchResultRecord evidence, exact batch/endpoint/file identity, physical-line framing and ordered prefix SHA-256 binding, deterministic early close, replay from byte zero, suppression through an exactly reproduced checkpoint, and fail-closed detection of changed or truncated acknowledged prefixes. It preserves strict finite-JSON validation and post-handoff no-replay behavior. The assurance boundary remains prefix-only: it does not claim provider authentication, unseen-suffix immutability, tenant authorization, or distributed exactly-once delivery.

Coverage RCA and repair

Earlier exact source e716b9e9f4a7f4f8613d19de25e15cb81ca0761a reached 99.94% because the public streaming wrapper rejected malformed limits before the separate defense-in-depth guard in result_streaming_checkpoint_impl.py could execute. Commit 997e652225e2aacc0e568aae298374a5ec440957 adds the focused internal regression that directly exercises that independent guard. Repository CI, Security Scan, SAST Semgrep, and Release Acceptance on 997e652225e2aacc0e568aae298374a5ec440957 were terminal-success; that evidence is predecessor evidence only after the current-main composition below.

Current-main composition

Protected main advanced to a3ffab60c7889130114d065a65c1dd669a92fd9d. Fresh comparison from the earlier branch base to that protected head showed the protected advances touch only Dockerfile, docs/doctoring/component-image-reproducibility.md, pg_llm_batch/batch_api_client.py, pg_llm_batch/db.py, tests/test_component_image_reproducibility.py, tests/test_db.py, and tests/test_virtual_payload_integrity.py; none overlaps this PR's eight changed paths.

Current contributor head 75263af18d112309390ac454cb54f1a9d2703344 is therefore a non-destructive two-parent composition of prior checkpoint head 997e652225e2aacc0e568aae298374a5ec440957 with exact protected main a3ffab60c7889130114d065a65c1dd669a92fd9d, preserving both disjoint results. GitHub reports the PR Draft and mergeable against that live base. Formal reviews and unresolved inline review threads were zero at the latest pre-write inspection.

Fresh repository CI, Security Scan, SAST Semgrep, and Release Acceptance for 75263af18d112309390ac454cb54f1a9d2703344 are currently queued. Queued evidence is not acceptance.

No schema, migration, credential, scheduler, model, or release authority is introduced.

Promotion boundary

Keep Draft until one unchanged exact current head has terminal-success Python 3.10/3.12/3.14, exact 100% owned production statement/branch coverage and public docstrings, package/container, Security Scan, SAST, Release Acceptance, every live required central workflow, zero valid unresolved findings, live-base mergeability, and every approval requirement actually imposed by the live ruleset. After promotion to Ready, reacquire any gate retriggered by that state transition before merge. No predecessor/queued/pending/skipped-required/status-only/author-only evidence is final acceptance.

[coderabbitai]

Warning

Review limit reached

@seonghobae, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 106 minutes

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

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: b225ae40-b7b3-41a8-a5d3-38e5e8b5793a

📥 Commits

Reviewing files that changed from the base of the PR and between 51af504 and 487e8d7.

📒 Files selected for processing (8)

• docs/adr/0006-resumable-result-checkpoints.md
• docs/doctoring/resumable-result-checkpoints.md
• docs/result-streaming.md
• pg_llm_batch/__init__.py
• pg_llm_batch/result_streaming.py
• pg_llm_batch/result_streaming_checkpoint_impl.py
• tests/test_resumable_result_checkpoint_coverage.py
• tests/test_resumable_result_checkpoints.py

---

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