sdk: ignore panics due to stray goroutines logging after a test completes #6632
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…etes
If there is imperfect goroutine lifespan tracking if we pipe our logs
through testing.T.Logf there is a chance of a stray goroutine attempting
to log after the test that spawned it completes.
This results in a panic of:
panic: Log in goroutine after TestLeader_SecondaryCA_Initialize has completed...
This isn't great and should be fixed, but quickly runs into situations
around externally cancelling blocking queries which isn't terribly
possible at the moment. The concession here is to ignore these specific
panics for now.
This can be triggered easily when running some tests with a high
`-count=YYY` value.
banks
approved these changes
Oct 17, 2019
There was a problem hiding this comment.
I agree that it would be ideal to be able to fix goroutine handling at source but since that's not something we can meaningfully address in the short term without rearchitecting major stuff in Consul this seems like a reasonable way to improve consistency in our tests.
rboyer
added a commit
that referenced
this pull request
Oct 17, 2019
…etes (#6632) If there is imperfect goroutine lifespan tracking if we pipe our logs through testing.T.Logf there is a chance of a stray goroutine attempting to log after the test that spawned it completes. This results in a panic of: panic: Log in goroutine after TestLeader_SecondaryCA_Initialize has completed... This isn't great and should be fixed, but quickly runs into situations around externally cancelling blocking queries which isn't terribly possible at the moment. The concession here is to ignore these specific panics for now. This can be triggered easily when running some tests with a high `-count=YYY` value.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
If there is imperfect goroutine lifespan tracking if we pipe our logs
through testing.T.Logf there is a chance of a stray goroutine attempting
to log after the test that spawned it completes.
This results in a panic of:
This isn't great and should be fixed, but quickly runs into situations
around externally cancelling blocking queries which isn't terribly
possible at the moment. The concession here is to ignore these specific
panics for now.
This can be triggered easily when running some tests with a high
-count=YYYvalue.