Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
A race condiiton could occur when setting the redis for the view tracker
This commit moves the creation of the view tracker and subscription to active support notifications until after we have run the users custom config block... previously the view tracker would run before a users custom config could set the store `config.store` with a redis URL... So it would default to REDIS_URL from the env, even if the user set it to say COVERBAND_REDIS_URL in their custom config... This bug could only effect folks that had multiple redises and were trying to run Coverband on a Redis that wasn't associated with the REDIS_URL env. When this bug occered we would save view_tracker information tot he REDIS_URL redis instance and then report them from the on configured by the users custom config.
- Loading branch information
08726b5
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.
Great catch! Would be great to have a way to expose this type of initialization issue in our tests. Something that initializes coverband in a bunch of different possible ways and ensures coverage is getting captured. For that we would need the test to be forking a new process each time.
08726b5
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 I couldn't really figure out a good way to test this... I am thinking perhaps we could ensure nothing tries to save or send any coverage without first having called configure... That is probably something we could test even without forking and having to kick everything off and ensure coverage was collected... This was definitely a subtle and hard thing to figure out so trying to find a better way to test for it would be good