Repository navigation
refactor(filters): standardize error payloads for all error types - #475
Merged
Cjay-Cyber-2 merged 1 commit intoOct 22, 2026
Conversation
Errors forwarded by Nest from outside its request pipeline (body-parser rejections, middleware next(err) calls) kept their raw Express shape, so an oversized body surfaced as a 500 and clients saw more than one error schema. Extract the problem-details mapping into one module used by the global filter and resolve the Express-style status/statusCode shape to the same RFC 9457 envelope. Closes ASTROIDX556#296 🤖 Generated with Codebuff Co-Authored-By: Codebuff <noreply@codebuff.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Standardizes every API error response on one RFC 9457 problem-details payload, including failures raised before a request reaches a controller.
Why
The global filter already emitted the envelope for application errors, but Nest forwards pre-route failures (body-parser rejecting malformed JSON, oversized payloads, middleware
next(err)calls) as plain Express errors. Those bypassed the mapping, so an oversized body surfaced as500 INTERNAL_ERRORand clients had to handle a second error shape.What changed
HttpException, request-id resolution, problem builder) intoproblem-details.util.ts— a single source of truth for the schema.err.status/err.statusCodeshape: client errors keep their real status and mapped code (413Payload Too Large, 415, 403, …), while unexpected 5xx errors keep the generic detail so nothing internal is exposed.Related issue
Closes #296
closes #288
closes #289
closes #290
Checklist
npm run buildpassesnpm testpasses (1903 tests)npm run lintpassesnpm run typecheckpasses