fix(rate-limit): bound stream retention - #650
Conversation
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthrough요청 및 결정 스트림 리더가 청크 배열 대신 고정 크기 Changes스트림 저장소 변경
Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
seonghobae
left a comment
There was a problem hiding this comment.
Current exact f59fce008a4da70f89e9927f692b823506594ed5 reviewed across the production diff, retained-storage regression, distributed rate-limit operating documentation, and CHANGELOG convergence. No additional valid source/test/DDD/owner-boundary finding remains in this exact diff. This is a COMMENT-only source review, not self-approval; merge authority still requires all required hosted gates to finish terminal GREEN on this exact head, zero unresolved review threads, and an unchanged live base/head check immediately before merge.
Finding
Fresh protected
main@5eb40da90bc18fc0fee7c18bfa86a337968fd3fbretained every accepted stream chunk in both distributed rate-limit bounded readers: the 256-byte internal request and the 4,096-byte Durable Object decision response. Both paths enforced authoritative byte ceilings but keptchunks[]until EOF and then allocated/copied into a second contiguous buffer, so legal high-fragmentation streams could make retained chunk-object/backing-store count scale independently of the byte limit.Reality RED
Test-only exact
b461c68369fe78d39b335e4353d287f3c5d85207added executable retained-storage regressions while leaving production source unchanged. Hosted application CI34640763052checked out that exact head, passed base/toolchain/install/typecheck, then failed atrelease tests, establishing the intended RED rather than an infrastructure failure.Causal repair
Production repair
74791910c8865ce82e2eba61a1523d251b9976cbreplaces per-chunk retention in both readers with one preallocated boundedUint8Array, rejects an oversize chunk before copying it, writes accepted bytes directly at the current offset, and decodes only the receivedsubarray. Existing fail-closed cancellation, malformed-body handling, fatal UTF-8/duplicate-key/JSON admission, configured byte ceilings, bucket semantics, identity authority, and Durable Object ownership remain unchanged.Documentation convergence is included on the current exact candidate
f59fce008a4da70f89e9927f692b823506594ed5:docs/distributed-rate-limiting.mdrecords the 256/4,096-byte fixed-buffer retention boundary and keeps deployed heap/p95 as separate evidence;CHANGELOG.mdrecords PR #650 under Unreleased without promoting source hardening to immutable release or production outcome authority.All required hosted gates must be terminal GREEN on this current exact head before Ready/merge. Predecessor GREEN will not be reused.
Owner boundary
This lane is confined to Noema's distributed rate-limit Durable Object transport/storage hygiene. It does not change rate-limit truth or bucket semantics, identity authority, credentials, provider/model routing, foreign outbound or quarantine authority, release/deployment, or production KPI authority. Source-level retention hardening is not immutable release, deployed heap/p95 evidence, or a production outcome.
Summary by CodeRabbit
/exchange및 분산 rate limit 처리에서 요청과 결정 본문을 고정 크기 버퍼로 읽도록 개선했습니다.