Closed jscaltreto closed 1 year ago
Nice! Thanks for submitting this PR! I'll have a look into it.
Perfect! Thank you for your PR. It will go into the development
branch, that will be released soon.
Base: 91.95% // Head: 91.95% // No change to project coverage :thumbsup:
Coverage data is based on head (
492443b
) compared to base (dee726b
). Patch has no changes to coverable lines.:exclamation: Current head 492443b differs from pull request most recent head ce1d978. Consider uploading reports for the commit ce1d978 to get more accurate results
:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
Currently, when
Check.MaxContiguousFails
is set ton
the firstn-1
checks will returnStatusUp
even if it and all prior checks were a failure. This is becauseevaluateCheckStatus
only returnsStatusDown
if the number of consecutive failures is >=MaxContigiousFails
. The result is that on startup the status may be reported as Up when it has never actually had a successful check. The fix for this is to also return StatusDown if there were no previous successes (check thatLastSuccessAt
is notnil
).Additionally, this implements
Check.MinContiguousSuccesses
andCheck.MinTimeInSuccess
which function as the inverse ofCheck.MaxContiguousFails
andCheck.MaxTimeInError
, respectively.MinContiguousSuccesses
consecutive checks before it's considered healthy.MinTimeInSuccess
duration before it's considered healthy.If either threshold is not satisfied then the most recent
check.Status
is returned; this is so that on startupStatusUnknown
will continue to be returned until the threshold(s) are reached to avoid returning a misleadingStatusDown
.