Fix global failed status when multiple fatal checks have mixed results #50
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello, first of all thank you for this library!
I really like the effective and simple implementation.
I found a bug that I suspect is a race condition in the global status when there are multiple fatal checks with mixed order.
Given the presence of multiple fatal checks, some failing and some passing, if the order of execution makes the passing check end last the global status was reported as
ok
even if otherfatal
check were in afailed
state.Looking at the code, each goroutine was updating the
h.failed
"thread-global" variable at the end of it's check cycle. This makes theh.failed
variable to have the last value set by a goroutine in order of exectuion time.If a successful fatal test run after a failing one, the
h.failed
variable was reportingtrue
.To reproduce the bug I updated the test cases
and
to use two checkers instead of one, both fatal but one failing and one passing, ordered such that the passing check was executed after the failing one.
( You can still test this at commit 1fa23aa )
This PR adds a little feature and implements a fix for this behaviour.
Feature
Add
Fatal
field in theState
struct.This information is really helpful when multiple checks (mixed fatal and not fatal) are present and the global status is
failed
.With this information exposed is clear which check is making the global status to fail.
The bugfix is based upon the
Fatal
field exposed in theState
struct, this could be reworked but I found theFatal
to be useful there anyway.Bugfix
Remove the
h.failed
boolean and rely only onState
information to evaluate the condition.With this implementation the
h.Failed()
function relies onsafeGetStates
to reported last known status.Thank you for looking into this!