🚀 Feature Proposal
Currently while fastify is shutting down, all APIs returns 503.
I would like to make this behaviour configurable.
Motivation
In Kubernetes, when a deployment is updated, the process receives a SIGTERM. After that, your container continues to receive incoming requests. With the current behaviour all those responses are 503, even if the process is able to serve them.
So, I cannot directly attach the SIGTERM event to fastify.close method.
Example
const fastify = require('fastify')({ returns503OnClose: false }) // default trueThe changes involve those lines:
|
avvio.once('preReady', () => { |
|
fastify.onClose((instance, done) => { |
|
fastify[kState].closing = true |
|
router.closeRoutes() |
|
if (fastify[kState].listening) { |
|
instance.server.close(done) |
|
} else { |
|
done(null) |
|
} |
|
}) |
|
}) |
where the router.closeRoutes() is done only if the flag returns503OnClose is set to true.
NB: According to node documentation the callback will be called only when all connections are closed, so no requests are discarded.
Edit:
old conversation #886
🚀 Feature Proposal
Currently while fastify is shutting down, all APIs returns 503.
I would like to make this behaviour configurable.
Motivation
In Kubernetes, when a deployment is updated, the process receives a SIGTERM. After that, your container continues to receive incoming requests. With the current behaviour all those responses are 503, even if the process is able to serve them.
So, I cannot directly attach the SIGTERM event to
fastify.closemethod.Example
The changes involve those lines:
fastify/fastify.js
Lines 240 to 250 in 901911c
where the
router.closeRoutes()is done only if the flagreturns503OnCloseis set totrue.NB: According to node documentation the callback will be called only when all connections are closed, so no requests are discarded.
Edit:
old conversation #886