Rename gracefulShutdown to return503OnClosing to align the HTTP
option name with Fastify's terminology. The previous name was too
vague and could imply broader behavior (connection draining, grace
periods) beyond what it actually does.
Move isShuttingDown flag activation from dispose() to a new
prepareClose() step that runs before callDestroyHook(). This prevents
new requests from being processed while providers are being destroyed
during shutdown.
Add beforeClose() to HttpServer interface and AbstractHttpAdapter so
adapters can be notified before the shutdown lifecycle begins.
Pipeline is great for when multiple streams need to be used together
but can also end up causing problems when there's a readstream of a
large file being sent in chunks, because the streams get destroyed
early. Technically, everything works fine, but there's warnings in
the terminal that could be misleading, so calling the streams with
error handlers directly is a safer way to go about it.
Express 5 made the router public API again and renamed the field from app._router to app.router.
This broke the detection mechanism whether a middleware named "jsonParser" or "urlencodedParser"
is already registered or not.
Unfortunately, https://github.com/nestjs/nest/pull/14574/ only fixed the issue partially.
This commit now uses app.router everywhere.
To avoid future regressions a test was added to verify the expected behavior.
Express 5 made the router public API again and renamed the field from app._router to app.router.
This broke the detection mechanism whether a middleware named "jsonParser" or "urlencodedParser"
is already re or not, because app._router no longer exists.
If user overrides the Content-Type but doesn't add a custom exception
filter to handle errors, then Nest will respond with a JSON error
object. We should ensure the Content-Type header matches the body
in this case.
`pipeline` ends up destroying streams used if there is an error in one of
the streams. Due to this, there's no chance of a memory leak from errored out
streams. There's also now an addition of adding an error handler to the
`StreamableFile` so that stream errors by default return a 400 and can be
customized to return an error message however a developer would like. These
only effect the express adapter because of how Fastify already internally
handles streams.
fix: #9759
