Skip to content
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

User subsystem: add profile update operations #4046

Merged
merged 134 commits into from
Jun 6, 2024
Merged

User subsystem: add profile update operations #4046

merged 134 commits into from
Jun 6, 2024

Conversation

pcapriotti
Copy link
Contributor

https://wearezeta.atlassian.net/browse/WPB-8880

Checklist

  • Add a new entry in an appropriate subdirectory of changelog.d
  • Read and follow the PR guidelines

@zebot zebot added the ok-to-test Approved for running tests in CI, overrides not-ok-to-test if both labels exist label May 10, 2024
Comment on lines 35 to 38
-- PERFORMANCE(fisx): if a user changes 4 attributes with one request, the database will
-- be hit with 4 requests (one for each attribute). this is probably fine as this
-- operation is not heavily used. (also, the four operations are batched, which may or
-- may not help.)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

anybody care to give a second opinion?

@@ -1,13 +1,72 @@
{-# LANGUAGE TemplateHaskell #-}
{-# OPTIONS_GHC -Wno-ambiguous-fields #-}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean? Is this scheduled to become an error in ghc? What's the replacement?

retry x5 $ write handleDelete (params LocalQuorum (Identity h))
let key = "@" <> fromHandle h
deleteClaim uid key (30 # Minute)
_ -> pure () -- this shouldn't happen, the call side should always check that `h` and `uid` belong to the same account.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is very old code. let's not touch it in this PR?

Comment on lines +99 to +106
-- | Simple updates (as opposed to, eg., handle, where we need to manage locks). Empty fields are ignored (not deleted).
UpdateUserProfile :: Local UserId -> Maybe ConnId -> UpdateOriginType -> UserProfileUpdate -> UserSubsystem m ()
-- | parse and lookup a handle, return what the operation has found
CheckHandle :: Text {- use Handle here? -} -> UserSubsystem m CheckHandleResp
-- | checks a number of 'Handle's for availability and returns at most 'Word' amount of them
CheckHandles :: [Handle] -> Word -> UserSubsystem m [Handle]
-- | parses a handle, this may fail so it's effectful
UpdateHandle :: Local UserId -> Maybe ConnId -> UpdateOriginType -> Text {- use Handle here? -} -> UserSubsystem m ()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not decided yet, that's why we left the question. :)

Comment on lines +99 to +106
-- | Simple updates (as opposed to, eg., handle, where we need to manage locks). Empty fields are ignored (not deleted).
UpdateUserProfile :: Local UserId -> Maybe ConnId -> UpdateOriginType -> UserProfileUpdate -> UserSubsystem m ()
-- | parse and lookup a handle, return what the operation has found
CheckHandle :: Text {- use Handle here? -} -> UserSubsystem m CheckHandleResp
-- | checks a number of 'Handle's for availability and returns at most 'Word' amount of them
CheckHandles :: [Handle] -> Word -> UserSubsystem m [Handle]
-- | parses a handle, this may fail so it's effectful
UpdateHandle :: Local UserId -> Maybe ConnId -> UpdateOriginType -> Text {- use Handle here? -} -> UserSubsystem m ()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think it's better to keep the question rather than making the impression to future readers that nobody has ever thought about this.

@@ -544,17 +561,18 @@ listActivatedAccountsH
u4 <- (\phone -> API.lookupAccountsByIdentity (Right phone) includePendingInvitations) `mapM` phones
pure $ u1 <> u2 <> join u3 <> join u4

-- FUTUREWORK: this should use UserStore only through UserSubsystem.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe resolve that now?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nah, next PR!

services/brig/src/Brig/User/Auth.hs Outdated Show resolved Hide resolved
@@ -52,28 +75,41 @@ newtype NotPendingStoredUser = NotPendingStoredUser StoredUser

instance Arbitrary NotPendingStoredUser where
arbitrary = do
user <- arbitrary
user <- arbitrary `suchThat` \user -> isJust user.identity
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because it's not trivial (nothing is, not even this conversation) and serves no practical purpose? sorry :). let's discuss in person if that doesn't convince you.

@@ -52,28 +75,41 @@ newtype NotPendingStoredUser = NotPendingStoredUser StoredUser

instance Arbitrary NotPendingStoredUser where
arbitrary = do
user <- arbitrary
user <- arbitrary `suchThat` \user -> isJust user.identity
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(i would prefer to think / talk about the question how to reduce the amount of assumptions that goes into this type. like, is an arbitrary user consistent if we merely change the status?)

services/brig/src/Brig/User/Auth.hs Outdated Show resolved Hide resolved
@@ -544,17 +561,18 @@ listActivatedAccountsH
u4 <- (\phone -> API.lookupAccountsByIdentity (Right phone) includePendingInvitations) `mapM` phones
pure $ u1 <> u2 <> join u3 <> join u4

-- FUTUREWORK: this should use UserStore only through UserSubsystem.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nah, next PR!

@fisx fisx merged commit 5d37f6c into develop Jun 6, 2024
9 checks passed
@fisx fisx deleted the update-profile branch June 6, 2024 09:19
@echoes-hq echoes-hq bot added echoes: technical-roadmap/throughput More specific category, to highlight task aiming at improving the development velocity and effici... echoes: technical-roadmap/technical-debt More specific category, to highlight Technical Debt being tackled. labels Jun 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
echoes: technical-roadmap/technical-debt More specific category, to highlight Technical Debt being tackled. echoes: technical-roadmap/throughput More specific category, to highlight task aiming at improving the development velocity and effici... ok-to-test Approved for running tests in CI, overrides not-ok-to-test if both labels exist
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants