You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 15, 2022. It is now read-only.
In setting up this library, I initially added a database check to both AddLivenessCheck and AddReadinessCheck. In looking at handlers.go, it looks like the ready handler will run both liveness and readiness checks. I didn't see this documented anywhere, so I assumed each only ran their own specific checks as added.
Would it be possible to either 1) document the behavior in the godoc and README, or 2) treat each as separate checks. Maybe expose a third more explicit method AddLivenessReadinessCheck() if someone wants to add to both.
If both checks are going to be combined, it might make sense to treat the name as a unique identifier and ensure the same check (which may be registered in both places) is not run more than once. Otherwise the ready checks may call (for example) db.PingContext() twice instead of once for a single /ready check from Kubernetes.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
In setting up this library, I initially added a
database
check to bothAddLivenessCheck
andAddReadinessCheck
. In looking athandlers.go
, it looks like the ready handler will run both liveness and readiness checks. I didn't see this documented anywhere, so I assumed each only ran their own specific checks as added.Would it be possible to either 1) document the behavior in the godoc and README, or 2) treat each as separate checks. Maybe expose a third more explicit method
AddLivenessReadinessCheck()
if someone wants to add to both.If both checks are going to be combined, it might make sense to treat the
name
as a unique identifier and ensure the same check (which may be registered in both places) is not run more than once. Otherwise the ready checks may call (for example)db.PingContext()
twice instead of once for a single/ready
check from Kubernetes.The text was updated successfully, but these errors were encountered: