Description
Audit dimension 2 confirmed a live defensive-resource defect at the v2.0.0 release tree. src/meraki_dashboard_exporter/app.py:1443-1456 extends the request buffer with each complete ASGI chunk before checking the configured maximum. With no trustworthy Content-Length, one chunk much larger than the cap is copied in full before the handler returns 413, so the documented hard application byte cap does not bound the application extra allocation. Existing tests at tests/unit/test_app_webhook_size_cap.py:47-114 use small producer chunks and assert only the response, not bounded accumulation.
Acceptance Criteria
- #1 A chunk larger than the remaining byte budget is rejected before it is copied into the application buffer
- #2 A focused regression supplies one oversized ASGI chunk and proves the accumulator never grows beyond the configured cap
- #3 Valid under-cap chunked requests and validation-failure accounting remain unchanged
Definition of Done
- #1 just check (ruff format –check, ruff check, mypy, generated-doc drift, offline API conformance, and the marker-filtered pytest run with the 80% coverage floor — this is exactly what the CI
testjob runs) - #2 just gen, when metrics, config, endpoints, collectors, the settings schema or the chart config changed —
just checkincludes the drift gate and CI fails the build on it - #3 Grafana queries in grafana/dashboards/*.json and grafana/alerts/ updated, if a metric or label name changed
Implementation Plan
Write an oversized single-chunk regression that instruments maximum accumulator size; compare each chunk with remaining capacity before extending while preserving under-cap and validation-failure behavior.
Final Summary
Rejected oversized webhook chunks before copying into the bounded buffer. Both intended regressions failed before the fix; just check and just ci passed at 5e8d9c23b76a2f2edd531c15c776cbfbcc9134fa; exact-head CI 33843833956 and publication 33843966820 succeeded.