Option for health check by default "healthy" about under-pressure HOT 5 CLOSED

The health check in my case is only executed after the provided healthCheckInterval, before that moment the health check isn't executed and thus unhealthy.

Please read the code, you can see it is executed at the right time.

from under-pressure.

By the look at the code, an externals health check is done during startup. So the scenario you are describing should not be possible.. or in other terms you are routing requests to Fastify before it has completed its bootstrap.

Can you please add a reproduction of this problem?

from under-pressure.

That is indeed strange. The health check in my case is only executed after the provided healthCheckInterval, before that moment the health check isn't executed and thus unhealthy.

See also your documention which confirms that:

"every X milliseconds, the time can be configured with the healthCheckInterval option.
every time the status route is called, if exposeStatusRoute is set to true."

And:

"By default when this function is supplied your service health is considered unhealthy, until it has started to return true."

But sure. I will try to create a git repo for reproduction if you want. Maybe the health handler is added during bootstrap but not executed right away.

from under-pressure.

Sorry Matteo, you are right of course... 👍🏽

The root cause was actually executing MySQL query (SELECT 1 ) in the health check function. This call failed (giving unhealthy), because the MySQL pool connection wasn't present during bootstrap. Moving the @fastify/mysql plugin registration above the under-pressure plugin registration solved that, since then the fastify.mysql.pool is present directly within the under-pressure health check.

However, once I fixed that, I got some other weird synchronization issues with Node, I added await on all the register calls I do now (even on autoload).

That popped-up another error "Fastify instance is already listening" for some reason. I moved fastify.setErrorHandler before registration the all the Fastify plugins. Even if I added await in front of fastify.setErrorHandler (and all register calls are also using await). But that didn't work.

Does setErrorHandler not return a promise just like fastify.register does? So setErrorHandler is unable to make it async (blocking).

Anyhow, I solved it now by executing the plugins in the right order with await, and then I fixed the "Fastify instance is already listening" issue by first register the setErrorHandler before my plugin registrations. 😅

from under-pressure.

Yea I think I'm correct setErrorHandler() is returning a Fastify instance object, not a promise like register() does. Hence I was seeing "Fastify instance is already listening", because I can't make setErrorHandler use await.

from under-pressure.