-
Notifications
You must be signed in to change notification settings - Fork 503
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
support/log: decouple logger and unit test concerns #4142
support/log: decouple logger and unit test concerns #4142
Conversation
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.
One comment, see below, non-blocking.
…e services/horizon
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.
One non-blocking suggestion, regardless, looks great to me 👏🏻. I'm no Horizon expert, so I defer to @ire-and-curses who had already commented.
PR Checklist
PR Structure
otherwise).
services/friendbot
, orall
ordoc
if the changes are broad or impact manypackages.
Thoroughness
.md
files, etc... affected by this change). Take a look in the
docs
folder for a given service,like this one.
Release planning
needed with deprecations, added features, breaking changes, and DB schema changes.
semver, or if it's mainly a patch change. The PR is targeted at the next
release branch if it's not a patch change.
What
investigation of intermittent failures during 'test race' condition checks on CircleCI jobs led to likely source being unit test hook/unhook state applied on default logger, if any unit tests happen to run in parallel, they would by default be using the same default logger and potentially collide on concurrent access to aspects of hooked state.
Why
First alternative is to add mutex/thread sync around hooked state access in logger, but that seemed to add more complexity and potential brittleness to test infrastructure. Decided to take further step back first and looked at why was unit test and logger so tightly bound, since they should be unrelated. The reason is some unit tests were using the hooked logger to capture log output and then assert on the the logged output. That approach is likely opinionated/subjective, my initial reaction is that logs are code mechanics and don't represent or infer app functionality.
The unit tests that were asserting on log outputs also were asserting on more concrete functional outputs of the system/unit, so I tried an approach here of removing the code that bound unit-test to logger which should remove the intermittent race condition, allow unit tests to be a bit more agnostic, idempotent for different runtime environments.
Closes #4121
Known limitations
If asserting on log outputs is a must, then will need to revert to different approach that applies mutex/thread sync into unit-test/log hooks.