-
Notifications
You must be signed in to change notification settings - Fork 207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tests: mitigate flaky snippets tests #432
Conversation
And now the docs, oh my. :) |
This |
|
# Yet, waiting on the stream shutdown should have completed *after* | ||
# the processing of received messages has ended. | ||
assert msg_done_lines[-1] < shutdown_done_waiting_lines[0] | ||
except AssertionError: # pragma: NO COVER |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't know about "pragma: NO COVER". Nice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, but it just shouldn't be overused. :)
This is one of the cases where it's the right tool, though, it makes the coverage check happy, since a passing test does never hit the "unhappy" path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Absolutely :)
Fixes #430. (maybe)
I was not able to reproduce flakiness locally, thus this PR is a best guess.
The test failure suggests that more than three messages were received, even though we only publish 3 messages in the test. This could be due to message re-delivery or because a topic might be shared between tests.
This PR reduces the total wait time in the message callback. It used to be 5 + 5 seconds, which is just the default ACK deadline, thus reducing that to 8 seconds might help. In addition, the test now prints the log output if one of the assertions fail, which will help with debugging, should the flakiness continue.
We could also use auto retries by
flaky
as a last resort, but let's see if we can fix the root cause first.(update: Yet I did this for the unrelated delete schema test, because it's quite often been flaky recently)
PR checklist: