-
Notifications
You must be signed in to change notification settings - Fork 21.6k
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
use ProxyPattern to match for ActiveSupport::Notifications fanout/unsubscribe #32861
Conversation
Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @schneems (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. This repository is being automatically checked for code quality issues using Code Climate. You can see results for this analysis in the PR status below. Newly introduced issues should be fixed before a Pull Request is considered ready to review. Please see the contribution instructions for more information. |
8392172
to
5c9279b
Compare
5c9279b
to
388cb66
Compare
Looks like there might have been some CodeClimate concerns but the analysis is out of date - can you merge in latest master so we can get an up to date build? |
388cb66
to
2c01532
Compare
@oniofchaos I think there was an issue in master when the previous build ran. I rebased on latest master; everything looks green now! |
b502722
to
fee6548
Compare
@jhawthorn you've looked at this code recently. Any opinions? |
end | ||
|
||
def ===(name) | ||
pattern === name && blacklist.none? { |p| p === name } |
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.
Can we use Set#include?
instead? Since we know name and everything in the set to be a string
@@ -39,8 +40,10 @@ def unsubscribe(subscriber_or_name) | |||
when String | |||
@string_subscribers[subscriber_or_name].clear | |||
@listeners_for.delete(subscriber_or_name) | |||
@other_subscribers.each { |sub| sub.blacklist!(subscriber_or_name) } |
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.
Can you change blacklist!
to "restricted_list" or maybe restrict!
.
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.
How about @unsubscribed
?
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.
Other than two comments this looks good to me.
fee6548
to
94f8e8c
Compare
Thanks @jhawthorn and @tenderlove. I've implemented your suggested changes. |
Great! Thank you! |
I'll merge this once CI returns. 😄 |
Summary
Before this change,
ActiveSupport::Notifications.unsubscribe
would eagerly remove all subscribers for whichsubscriber.matches?(string)
was true, which can cause some unintended behavior in the case of regexes or other compound matchers (in our case, we had a single listener subscribed to a few dozen event keys via a single pattern object that internally checked for inclusion within a set).Unsubscribing to a single string should not negate any other potential matches for those subscriptions. After this change:
listeners_for
map.