added bound

[koder-ns]

PR: Reject Oversized JSON Bodies with a Documented Client Error — API, Health & Shared Behavior

Problem / opportunity closes #1031

The API currently accepts arbitrarily large JSON request bodies on all inbound endpoints. This exposes the service to a class of avoidable risks:

• Denial-of-service / resource exhaustion — a single oversized payload can tie up parser memory and CPU, degrading or stalling healthy traffic on shared runtime threads.
• Correctness & contract clarity — clients receive no documented, deterministic rejection when their payload exceeds a sane limit. Behavior today is effectively "whatever Nest/Express does by default," which is not part of our API contract.
• Observability gap — oversized requests are not surfaced as an explicit, distinguishable client error, making it hard for API consumers and operators to diagnose 4xx vs. 5xx confusion.
• Security posture — unbounded body parsing widens the attack surface for memory-pressure and parser-abuse vectors on a service that shares runtime behavior (health checks, error filters) across all endpoints.

Scope (strict allowlist) closes #1032

This PR is limited to exactly these three files:

| File | Role | closes #1030
|---|---|
| BackendAcademy/src/main.ts | Enforce the JSON body size limit at bootstrap via the underlying HTTP adapter, and normalize the rejection into a documented client error. |
| BackendAcademy/src/app.module.ts | Wire the shared configuration (limit value / provider) so the behavior is centralized and testable. | closes #1033
| BackendAcademy/src/app.controller.spec.ts | Regression tests proving oversized bodies are rejected with the documented status and payload, and that valid bodies still pass. closes #1033

No DTOs, filters, interceptors, guards, or config files outside this list are modified. Any necessary types are declared inline within these three files.

Implementation outline

BackendAcademy/src/main.ts

• Apply a JSON body size limit to the underlying HTTP instance during bootstrap (e.g., via the framework's body-parser configuration on the Nest app), using a single named constant.
• Add a narrow, explicitly-typed error normalization step so body-parser's "entity too large" failure is converted into our documented 413 response shape rather than leaking a framework-specific error.
• Structured logging on rejection with request path, declared limit, and observed content length — no broad except/catch without logging.

BackendAcademy/src/app.module.ts

• Introduce a small, typed configuration provider exposing the body limit (bytes) as a single source of truth, consumed by bootstrap.
• Keep the module graph minimal — no new third-party dependencies, no changes to unrelated providers.

BackendAcademy/src/app.controller.spec.ts

• Regression tests:
  • Oversized JSON body → 413 with documented { code, message, limitBytes }.
  • Exactly-at-limit body → success (boundary correctness).
  • Small/valid body → success (no regression).
  • Assert the rejection is logged (spy on logger) and that no broad catch swallows it silently.
• Tests are self-contained and exercise the shared behavior through the app bootstrap path used by main.ts.

Testing requirements

• Relevant test suite green.
• New regression test covers both the reject path (oversized) and the accept path (at/under limit).
• No broad except:/catch without logging; rejection path emits a structured log entry.
• Run black, ruff, mypy (or the project's configured linters/type-checkers) on the touched files.

Risk & rollback

• Risk: low — scoped to bootstrap body-size enforcement plus tests; no business logic touched.
• Rollback: revert the three-file diff; behavior returns to prior defaults with no migration needed.

[drips-wave]

@koder-ns Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[MaryammAli]

LGTM