-
Notifications
You must be signed in to change notification settings - Fork 325
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
Move search operations to UserSubsystem #4188
Conversation
f8ceeb9
to
d765d9a
Compare
51287eb
to
1273d16
Compare
script :: ES.Script | ||
script = ES.Script (Just (ES.ScriptLanguage "painless")) (Just (ES.ScriptInline scriptText)) Nothing Nothing | ||
|
||
-- Unfortunately ES disallows updating ctx._version with a "Update By Query" |
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.
Not updating versions can cause issues while reindexing. This seems like an oversight, we should try to break it and create tickets accordingly.
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.
This doesn't block this PR.
libs/wire-subsystems/src/Wire/UserSearchSubsystem/Interpreter.hs
Outdated
Show resolved
Hide resolved
9ab91b3
to
14fa9dc
Compare
cb424d3
to
2c5dda0
Compare
50ea265
to
ea066db
Compare
Pending: - Index Management - Search - Metrics - Update brig to use the new code (currently, brig is just broken)
Some metrics have been deleted as they are for bulk operations and there is no way for us to get those metrics because these operations don't run in an http request.
16cf3af
to
7d0d0c7
Compare
type instance MapError 'NoUser = 'StaticError 403 "no-user" "The user does not exist" | ||
|
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.
What was the error before the refactoring?
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.
"TODO: searcher doesn't exist" :)
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 was asking about before this PR started. This PR is supposed to be a refactoring, so ideally we wouldn't be inventing new user visible errors. So it'd be great to know what was the previous behaviour.
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.
It seems like we've introduced this error, but for no good reason. I'm refactoring the code so we don't need to throw the error.
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.
This type instance is gone now and we don't throw a new error anymore compared to the old code.
-- TODO: This store effect is more than just a store, we should break it up in | ||
-- business logic and store | ||
-- FUTUREWORK: This store effect is more than just a store, | ||
-- we should break it up in business logic and store |
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.
Is this still work for this ticket? We moved the code from brig to wire-subsystems in this PR so it might be confusing for someone to see that it wasn't made to fit the nomenclature 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.
Is this still work for this ticket? We moved the code from brig to wire-subsystems in this PR so it might be confusing for someone to see that it wasn't made to fit the nomenclature here.
Is this a blocker for you or is a follow-up ticket OK?
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.
Follow up is also ok 👍
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.
This is just a partial review in case anyone has capacity to address my comments while I review the rest of the PR.
UpdateTeamSearchVisibilityInbound status -> | ||
updateTeamSearchVisibilityInboundImpl status |
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.
Shouldn't this one be in a team effect?
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.
This isn't a blocker for me.
BrowseTeam uid browseTeamFilters mMaxResults mPagingState -> | ||
browseTeamImpl uid browseTeamFilters mMaxResults mPagingState |
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.
This one too sounds like it belongs to a team effect.
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.
This isn't a blocker for me.
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.
Makes sense, but I think this would make a very weird first thing to implement in a TeamSubsystem
. Should we add a note here and move it later? Same for UpdateTeamSearchVisibilityInbound
.
@@ -397,6 +434,8 @@ updateUserProfileImpl (tUnqualified -> uid) mconn updateOrigin update = do | |||
guardLockedFields user updateOrigin update | |||
mapError (\StoredUserUpdateHandleExists -> UserSubsystemHandleExists) $ | |||
updateUser uid (storedUserUpdate update) | |||
let interestingToUpdateIndex = isJust update.name || isJust update.accentId |
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.
Why only these two are relevant here, and not others? Somewhere else we have a helper function that computes for an update if it is interesting. How do these two relate?
libs/wire-subsystems/test/unit/Wire/MockInterpreters/FederationConfigStore.hs
Outdated
Show resolved
Hide resolved
libs/wire-subsystems/test/unit/Wire/MockInterpreters/UserStore.hs
Outdated
Show resolved
Hide resolved
liftSem $ | ||
if success | ||
then do | ||
UserSubsystem.internalUpdateSearchIndex uid |
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.
Was something like this done in the version before this PR?
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 Intra.onUserEvent
did this.
@@ -335,7 +328,7 @@ createUser new = do | |||
|
|||
wrapClient $ Data.insertAccount account Nothing pw False | |||
liftSem $ GalleyAPIAccess.createSelfConv uid | |||
liftSem $ Intra.onUserEvent uid Nothing (UserCreated (accountUser account)) | |||
liftSem $ Events.generateUserEvent uid Nothing (UserCreated (accountUser account)) |
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.
No need to update the search index here?
If it needed, why did we pull out this updating? It just opens room for errors without any clear benefits to me.
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 activateUser
does that part.
The reason for pulling this out was that we were processing notifications meant for users as if they were intra backend communication which didn't seem very intuitive. Yes, this opens a room for bugs, but we have to trust our testing otherwise refactorings like this one would never happen.
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.
There are still a few things left to address, and I've pointed to them in my earlier reviews. Overall, this looks good, but please don't merge before addressing the remaining issues.
bf68cb4
to
567a8d3
Compare
https://wearezeta.atlassian.net/browse/WPB-8888
Checklist
changelog.d