This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Move update_client_ip
background job from the main process to the background worker.
#12251
Merged
Merged
Changes from 1 commit
Commits
Show all changes
13 commits
Select commit
Hold shift + click to select a range
2cb1ca5
Add assertions that some MAU updating methods only run on the backgro…
reivilibre 74efd6b
Fold MontlyActiveUsersStore into MonthlyActiveUsersWorkerStore
reivilibre 7d78a05
Add assertions that client IP update methods only run on a designated…
reivilibre b6bfb51
Fold ClientIpStore into ClientIpWorkerStore
reivilibre 1f21c93
Make the background worker handle USER_IP replication commands
reivilibre 4a5a076
Fold away SlavedClientIpStore
reivilibre fb57aef
Fix type annotations: device_id is Optional
reivilibre 9daa8d3
Newsfile
reivilibre 7aa5b84
Pull `is_guest` up into the `RegistrationWorkerStore`
reivilibre cf050d8
Add __repr__ for `UserIpCommand`
reivilibre 5d639a3
Only enable this functionality for Redis-based deployments
reivilibre faf0fd3
Add comments to explain obscure branching and return of None
reivilibre bbbb172
Inline the worker-specific handle_user_ip functions
reivilibre File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 think it would be clearer to inline
_handle_user_ip
intoon_USER_IP
? Otherwise its a bit confusingThere 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.
Only concern with that is that it will mean that uninvolved workers end up creating and scheduling coroutines as background processes as well, whereas they didn't before.
I don't know how much that worries us, but since the code was already structured this way for some reason, I didn't want to remove it without understanding.
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'm confused, I'm not talking about a functional change here?
_handle_user_ip
is only called byon_USER_IP
?What's confusing me really is that the
self._is_master or self._should_insert_client_ips
a) looks odd by itself, and b) is entirely redundant given_handle_user_ip
then does the exact same checks. You may as well just always callself._handle_user_ip
inon_USER_IP
, at which point having it as a separate function seems a bit silly?Or am I missing something here?
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.
on_USER_IP
returns eitherNone
or an awaitable. If it's an awaitable, it goes through extra stuff to schedule it as a background process; if it's justNone
then nothing happens.Notably, the function can't (easily/nicely) be inlined and still preserve this behaviour of returning
None
if there's nothing to do, as I'd have to makeon_USER_IP
anasync def
in order to run potentially two coroutines back-to-back.It may not be a big deal, but I wasn't sure and since replication overhead is pretty sensitive, I was a bit uncomfortable taking a leap of faith.
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.
OH. Right, with you now. How obscure.
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.
Yes, and it took me forever where to find the code that calls
on_%s
because the name is dynamically constructed and I forgot that we like%s
-formatting and was searching for"on_"
:')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 add a comment in
on_USER_IP
about the whole awaitable thing please?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.
Done — I also inlined the two specific
handle_user_ip
functions, since looking at them now, they're so short it wasn't buying any clarity.