glm-5.3-flash
05ebbef43e
Review 002 GW-15 [major]: /publish lost both claimed memory bounds in the GW-06 streaming rewrite. Unauthenticated POST /publish with chunked 'a'-forever (no newline) grew the heap with the upload until OOM, and each poll re-scanned the whole buffer (O(n^2) on top). - BufferedLines: cap the unterminated tail against MAX_PUBLISH_LINE_BYTES immediately after every chunk read (checked before yielding, even with no \n seen) and re-check on the trailing-EOF mem::take path; a breach aborts the whole reader (pending lines included) with the same terminal INVALID_INPUT LineCap error. Complete lines keep the baseline at-cap semantics. - Whole gateway router: explicit request-body-limit layer (GATEWAY_BODY_LIMIT = 2 MiB + 64 KiB framing headroom). A raw-Body handler never consults axum's DefaultBodyLimit (that is an extension extractors read), so /publish had no whole-body cap at all. The layer pre-rejects oversized declared Content-Length and wraps chunked uploads in a counting stream; both answer plain-text 413. It deliberately sits above the per-line cap so a single over-cap line still surfaces the semantic line-cap error. Upstream body read failures are not flagged as limit-exceeded (disconnects are not 413). - New wire tests: streamed never-newline over-cap rejections (both the streamed multi-chunk and trailing-EOF shapes), 413 on chunked over-limit uploads, 413 on oversized declared Content-Length, cap breach batched with complete lines, at-cap line still round-trips, declared-length over-limit pre-rejection. Module status mapping note (GW-16 tracks the drift): hand-rolled pre-dispatch rejections use 400/INVALID_INPUT while mid-stream chunk errors map 422 through gateway::error; normalizing is GW-16, not GW-15. Verification: cargo test 305+5 pass, cargo test --all-features pass, cargo clippy --all-targets -- -D warnings pass (--all-features too), cargo fmt --check pass.