fix(nest): honor routed request during input decoding - #1922

✅ No new issues found.

Reviewed changes

• Decode input from the routed request — ImplementInterceptor now builds decodeInput from the request parameter passed to resolveProcedure (the request after routing interceptors run) instead of the closed-over initial standardRequest, so plugins that replace the request — such as RequestLimitHandlerPlugin — take effect during Nest input decoding. This matches the canonical pattern already used by the built-in OpenAPIHandlerCodecCore.resolveProcedure (decodeInput: () => this.decodeInput(matched, request)).
• Regression test for request-limit enforcement — a new request limit plugin test posts an over-limit body to a POST /request-limit procedure on both the Express and Fastify adapters and asserts 413 with PAYLOAD_TOO_LARGE.

I verified the test genuinely pins the bug: reverting the implement.ts fix makes both new tests fail with expected 200 to deeply equal 413 — i.e. the request-limit plugin is bypassed without the change. The full packages/nest/src/implement.test.ts suite (90 tests) and ESLint pass on the changed files.

One scoping note (not actionable): route params for decoding still come from the pre-routing standardRequest (per the PR's stated intent), while URL, query, and headers now come from the routed request. A routing interceptor that rewrites the request URL would therefore not affect Nest route-param extraction — consistent with the PR's declared scope.

  ^{｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}