-
-
Notifications
You must be signed in to change notification settings - Fork 7k
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
Fix deletes not reaching every server that interacted with status #15200
Conversation
I'm ok with the general idea, and factoring it out looks cleaner and is easier to reason about. As for the failing test, I have to admit I have no clue what's going on, for some reason I don't understand, It should also be noted that instances that fetched the toot in any way without actually interacting with it won't necessarily get a delete, and it mostly relies on intermediary instances forwarding the |
6951d54
to
35b880c
Compare
The unit test caught a real issue. Reblogs were removed before |
35b880c
to
43f78d6
Compare
I also identified some inefficies. When removing a reblog, the class would make queries for the reblog's mentions, media attachments, tags, etc. Since reblogs don't possess those, we can cut down on those queries. Also, due to using |
8213d6a
to
1542816
Compare
Extract logic for determining ActivityPub inboxes to send deletes to to its own class and explicitly include the person the status replied to (even if not mentioned), people who favourited it, and people who replied to it (though that one is still not recursive)
1542816
to
caaca9a
Compare
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.
Good catch with the reblogs stuff. This seems better overall, but there's one thing I'm not sure about (though it shouldn't be a big issue), see inline comments.
@status.active_mentions.find_each do |mention| | ||
redis.publish("timeline:#{mention.account_id}", @payload) | ||
end |
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 understand this is to avoid fetching account information from the database, but this will send events about remote accounts to redis. Is it worth it? Does it make sense?
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.
You’re right... but publishing to a channel with no subscribers should be O(0) so probably fine this way.
Extract logic for determining ActivityPub inboxes to send deletes to to its own class and explicitly include the person the status
replied to (even if not mentioned), people who favourited it, and people who replied to it (though that one is still not recursive)