I found that this project already supports Go modules. But sadly, the tags doesn't follow Semantic Versioning, which means that all tags of this project will be ignored by Go modules and replaced by pseudo-versions, go get acts weirdly when tags are not in that form. It would be great to have the tagged release be named in the format vX.X.X format so that go mod can read it.

	github.com/etherlabsio/healthcheck v0.0.0-20191224061800-dd3d2fd8c3f6

Else the mod file shows something like github.com/etherlabsio/healthcheck v0.0.0-20191224061800-dd3d2fd8c3f6 which is not very readable and difficult to upgrade. It’s hard to verify which version is in use. This is not conducive to version control.

So, I propose this project to follow Semantic Versioning in future versions. For example, v1.0.1, v2.0.0, v3.1.0-alpha, v3.1.0-beta.2etc, so that other project can use tag in go.mod.

Health Checks are called frequently, hence latency should ideally be low. Since most checks are to dependencies over the network, we need to make sure to timeout if the calls are not served within time.

While it's the responsibility of each checker func to maintain it's own TTL, having a max timeout value for a health check request might be a good idea.

This could be an optional feature.

Your FOSSA integration was successful! Attached in this PR is a badge and license report to track scan status in your README.

Below are docs for integrating FOSSA license checks into your CI:

• CircleCI
• TravisCI
• Jenkins
• Other

It's better to set a safe timeout default rather than use the default value of 0. 30s might be too high for most health checks, and it has to be specific for every application.

By default, any error occurring in the checker responses leads to a 503 HTTP status code. But we may not want to fail the healthcheck in case certain dependencies fail (eg: metrics service, s3 etc) but would like to observe the errors in the response for taking further action.

Fixes #5 If we decide to export the private timeoutChecker introduced here, It could also solve checker specific timeouts. All one has to do is to wrap an existing timer with a timeout checker.

Added the coverage test to circleci artifacts. I believe that the badge in the markdown should pick this up once it is updated. Not sure as I have not really used circleci much.

Resolves #11

Since Healthcheck usually checks dependencies present over the network there is a possibility of making multiple IO calls. Right now we are calling the check() function serially, so we'll wait till the function is returned. By using goroutines and waitgroup, we can make the calls more concurrent and hopefully reduce the overall latency of the healthcheck API.

Since healthcheck API's are called frequently, lower latecy response time is imperative.

PS: We'll also need to maintain an overall TTL for the healthcheck request. But that's a different issue to be addressed.

The handler uses context.Background() in the http handler. If the client (calling service) drop the connection, the processing will continue till an error occur when the handler tries to write a response.

If there is a time out before the checker is able to complete, then the goroutine started by the timeout checker forever waits to write on a channel.

type timeoutChecker struct {
	checker Checker
}

func (t *timeoutChecker) Check(ctx context.Context) error {
	checkerChan := make(chan error)
	go func() {
		checkerChan <- t.checker.Check(ctx) // cannot write here to the channel, no reader
	}()
	select {
	case err := <-checkerChan:
		return err
	case <-ctx.Done():
		return errors.New("max check time exceeded")
	}
}

Declaring the channel with size of 1 fixes the bug.

In addition to a common and overall timeout value defined for all health checkers, it'll be useful to override with a specific timeout value for a checker.

Concern: My assumption is that it will be useful for smaller timeout values when compared to an overall timeout across all checkers, when we want to guarantee strict response times of the dependency.

Does it even make sense to allow a higher value than the overall checker limit ? How would the implementation change.