security(request): reconstruct zero-progress guard on protected main

[seonghobae]

Purpose

Reconstruct PR #201's bounded request-stream progress fix on the exact current protected main without transferring predecessor checks/reviews. The original defect allowed an attacker- or bug-controlled request source to emit unbounded exact empty bytes chunks that consumed CPU without increasing max_request_bytes or reaching an HTTPCore network write.

Exact current identity

• live protected base: 7faf7a3b8a47980113982914000e724ab6a6cda5;
• predecessor PR security(request): reject zero-progress body chunks #201 head: 50b9951255485c3fd557d2bfd14fb6f9acbf490c (historical lineage only);
• exact reconstruction head: 77f5e287d6032a2eecc86a09b3888a4e14de974e;
• state: open / Draft / mergeable;
• reconstruction commit retains the predecessor as first parent and protected main as second parent;
• main-relative scope remains exactly CHANGELOG.md, src/egressweave/request_body_safety.py, and tests/test_request_body_empty_chunks.py;
• formal reviews: none;
• unresolved review threads: none.

Historical RED/GREEN checks/reviews from #201 do not transfer.

Security / compatibility boundary

The reconstructed delta:

• requires exact built-in bytes request chunks before progress accounting;
• permits one exact empty compatibility chunk but does not dispatch it to HTTPCore;
• rejects a second consecutive zero-progress chunk before dispatch;
• deterministically closes denied sync/async sources and emits the generic non-leaking denial;
• preserves ordinary non-empty exact bytes, declared-length parity, single consumption, authority/DNS/TLS/proxy/framing/resource limits and process-control exception semantics.

A non-empty chunk consumes the finite request-byte budget, so the one-empty-chunk compatibility allowance cannot be combined with bounded non-empty progress to create an unbounded zero-progress stream.

Exact-current-head evidence

On unchanged 77f5e287d6032a2eecc86a09b3888a4e14de974e:

• repository CI run 31636858472: completed success;
• SAST Semgrep run 31636858444: completed success;
• GHAS CodeQL check 94249461015: completed success with no new changed-code alerts;
• GHAS Semgrep OSS check 94249452062: completed success with no new changed-code alerts;
• Security Scan run 31636858406: aggregate success, with OSV, Trivy and Scorecard jobs successful, but dependency-review job 94249270015 skipped the actual immutable-pinned Dependency review action; aggregate green is therefore non-passing supply-chain evidence;
• OpenCode exact-head check 94249496607: completed success as model/check evidence only;
• required Strix exact-head check 94249272702: completed success with zero annotations and produced an exact-head strix-reports artifact 9157700816, SHA-256 153a09cccd9c23224d4391fa3fd285a251de8ec50f63d148247a6974bc532186;
• formal reviews: none;
• unresolved review threads: none.

Skipped/manual-status-only/model-only evidence is not promoted into merge acceptance.

Remaining acceptance

1. Keep this PR Draft while the organization-owned Dependency Review semantic gate is non-passing.
2. After an accepted protected-central Dependency Review repair reaches authority, obtain a fresh Security Scan on this unchanged accepted tree and require the real immutable-pinned Dependency Review action to execute and succeed.
3. Revalidate the exact current Strix artifact/check and every other required workflow against the unchanged current head; no predecessor, synthetic merge, skipped, neutral, status, model, or stale evidence transfers.
4. Validate any new human/automated finding against the exact current head and resolve only addressed threads.
5. Immediately before integration, refetch exact head, independently resolved live base, ancestry, live ruleset, all required workflows, reviews/findings/threads and writer evidence.
6. Merge only an unchanged accepted tree through normal governance; do not self-approve, bypass, weaken a gate, or churn the clean head solely to retrigger an external provider.

Supersedes #201 as the current-main implementation lane.

[coderabbitai]

Warning

Review limit reached

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

Next review available in: 56 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: d03e79a1-5734-41bc-b5e0-64935c8a966e

📥 Commits

Reviewing files that changed from the base of the PR and between 7faf7a3 and 77f5e28.

📒 Files selected for processing (3)

• CHANGELOG.md
• src/egressweave/request_body_safety.py
• tests/test_request_body_empty_chunks.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.}

[seonghobae]

@coderabbitai review
@opencode-agent review
@cwl-noema-review review

Review exact current head 77f5e287d6032a2eecc86a09b3888a4e14de974e only against live protected main 7faf7a3b8a47980113982914000e724ab6a6cda5. Validate exact built-in bytes before accounting, one-empty-chunk compatibility without dispatch, denial and deterministic source cleanup on repeated zero-progress chunks, declared-length parity, single-consumption behavior, sync/async equivalence, generic non-leaking errors, and the bounded three-file scope. Submit a real current-head source-review verdict; do not mutate, merge, or infer approval from wrapper/check/model evidence.

[coderabbitai]

Rate Limit Exceeded

@seonghobae have exceeded the limit for the number of chat messages per hour. Please wait 12 minutes and 25 seconds before sending another message.

[seonghobae]

Current-head source review for 77f5e287d6032a2eecc86a09b3888a4e14de974e found no blocking defect in the bounded request-stream progress scope. Both sync and async wrappers require exact bytes, consume but do not dispatch one compatibility empty chunk, reject any later zero-progress chunk before network dispatch, retain cumulative/declared-length and single-consumption contracts, and use deterministic generic-denial cleanup. This is author-side review evidence only, not independent approval. Keep Draft until the corrected Dependency Review path executes successfully on the unchanged head and all live semantic-review gates are current and substantive.