await healthCheck(app) doesn't wait about node-healthchecks-api

[valdemon]

Hi @jahluwalia,

excuse me long waiting for an answer.
As far as I've understood your use case is to wait with further server initializations until all dependencies are healthy, right?

The await healthCheck(app); statement is supposed to wait until the health checks API endpoints are up and listening ( https://hootsuite.github.io/health-checks-api/ ).

Your use case (again if I understood it right) is specific, as it assumes that the server should be considered up & running only when all dependencies are healthy, which not always can be a desired behavior (consider WARN states of dependencies or the critical/non-critical semantic described in the README.md).

If you want to realize your case with the current functionality you could try following:

const healthCheck = require('healthchecks-api');

// a helper method which will wait until all dependencies have desired states
// one can improve it with some timeout-wise approach (calling `reject`in case of a timeout).
const waitForHealth = (service, states = [ 'OK', 'WARN' ]) => new Promise((resolve, reject) => {
    const checkHealth = () => {
        for (let i=0; i < service.checks.length; i++) {
            let check = service.checks[i];
            if (!states.includes(check.status.status[0])) {
                setTimeout(checkHealth, 1000);
                return;
            }
        }
        // all dependencies healthy
        resolve();
    };
    checkHealth();
});

const startServer = async () => {
    const app = express();
    // the service object will be passed to health check init method where it gets decorated with initialized health checks and then used in further processing
    const service = {};
    
    // pass the `service` object in initialization options 
    await healthCheck(app, { service });

    // wait until all endpoints are healthy
    await waitForHealth(service, ['OK']);
    // rest of initialization steps
}

startServer();

I'll possibly incorporate this helper function in one of next releases.

[HootAdam]

One small note. As it is totally possible to not start the server until the dependencies are healthy, it isn't very helpful for the server. Once the status endpoints are registered, you can query the server to see if it is healthy. We moved away from this pattern as it doesn't always work. Sometimes a service can partially work (in a degraded state) when certain dependencies are down and not starting it can cause more harm than good.

[HootAdam]

Sorry, pressed wrong button. Did not mean to close :(

[valdemon]

Must agree with @HootAdam that blocking a server start until dependencies are healthy is far away from a common pattern (I've mentioned this already in the previous comment), especially that the server lifecycle is much longer than its start & initialization time and dependencies outages are something acceptable (don't mistake with desired ;) ).
They are subjects to deal with - according to https://www.reactivemanifesto.org/ and in particular health checks are provided to support such outage management (likely in some automated way).
Dependencies outages at the server start & initialization don't differ in this context with any other outages during the server life cycle.

If we would for example think of a use case like some server initialization related sub-process, that would be supposed to wait until eg. a database is up & running because it reads/writes something from/into it - I think that such a process cannot rely on our health checks as the information what they give is a function of time. It means that even when you request for the particular dependency health and the response is OK this can be false even some milliseconds after.
I'd rather design such a process with some retrial strategy for database read/write.

@jahluwalia maybe you could put some more light on the matter by describing your real use case here? Maybe we're missing something?

[jahluwalia]

@HootAdam and @valdemon,

Thank you for your comments and advice. I think relying on the healthcheck is probably not the way to go. I'm going to be reevaluating.

thanks,
jas

[valdemon]

Closing, as the issue author agreed on above clarifications.