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

Use MLS member table indexed by group id #2859

Merged
merged 10 commits into from
Nov 25, 2022

Conversation

smatting
Copy link
Contributor

@smatting smatting commented Nov 21, 2022

This PR adds a table galley.mls_group_member_client (indexed by group id) which replaces galley.member_client (index by conv). Motivation: This table may be used by MLS subconversations. This PR also includes a data migration from galley.member_client to galley.mls_group_member_client (tested locally).

Checklist

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

@smatting smatting temporarily deployed to cachix November 21, 2022 18:08 Inactive
@smatting smatting temporarily deployed to cachix November 21, 2022 18:08 Inactive
@zebot zebot added the ok-to-test Approved for running tests in CI, overrides not-ok-to-test if both labels exist label Nov 21, 2022
cassandra-schema.cql Outdated Show resolved Hide resolved
@smatting smatting force-pushed the fs-901/preparation-member-clients branch from 15704bd to 5f562b9 Compare November 23, 2022 13:04
@smatting smatting temporarily deployed to cachix November 23, 2022 13:04 Inactive
@smatting smatting temporarily deployed to cachix November 23, 2022 13:05 Inactive
@smatting smatting force-pushed the fs-901/preparation-member-clients branch 2 times, most recently from 87a11d6 to 2c1c036 Compare November 23, 2022 17:00
@smatting smatting temporarily deployed to cachix November 23, 2022 17:00 Inactive
@smatting smatting temporarily deployed to cachix November 23, 2022 17:00 Inactive
@smatting smatting temporarily deployed to cachix November 23, 2022 17:08 Inactive
@smatting smatting temporarily deployed to cachix November 23, 2022 17:08 Inactive
@smatting smatting marked this pull request as ready for review November 23, 2022 17:09
@smatting smatting temporarily deployed to cachix November 24, 2022 09:30 Inactive
@smatting smatting temporarily deployed to cachix November 24, 2022 09:30 Inactive
@smatting smatting temporarily deployed to cachix November 24, 2022 10:40 Inactive
@smatting smatting temporarily deployed to cachix November 24, 2022 10:40 Inactive
@smatting smatting force-pushed the fs-901/preparation-member-clients branch from 7a89f33 to e2f47c8 Compare November 24, 2022 11:08
@smatting smatting temporarily deployed to cachix November 24, 2022 11:08 Inactive
@smatting smatting temporarily deployed to cachix November 24, 2022 11:09 Inactive
Copy link
Contributor

@mdimjasevic mdimjasevic left a comment

Choose a reason for hiding this comment

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

Looks good! There are some questions I have though; see them inlined. In particular, if possible it'd be great to avoid conditional execution of various MLS actions if we're in a function that deals with MLS conversations only.

Comment on lines 329 to 330
for_ (Data.mlsMetadata (tUnqualified lconv')) $ \meta ->
traverse_ (removeUser lconv' (cnvmlsGroupId meta)) victims
Copy link
Contributor

Choose a reason for hiding this comment

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

You said the SConversationLeaveTag case applies to MLS only, hence this protocol-constrained removal is fine?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, the removeUser function is from the MLS modules. It only applies to MLS conversations, that's why it's okay to require the MLS metadata as argument

Comment on lines +609 to +611
let curEpoch = cnvmlsEpoch mlsMeta
groupId = cnvmlsGroupId mlsMeta
suite = cnvmlsCipherSuite mlsMeta
Copy link
Contributor

Choose a reason for hiding this comment

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

This now allows to drop the Member (ErrorS 'ConvNotFound) r constraint from this function: it is not thrown directly here anymore, nor applyProposalRef needs to throw it because it does have all the MLS metadata needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I could remove the ConvNotFound constraint from checkEpoch, but checkGroup still throws it. I refactored both functions to not used the converation object anymore but rather the ConversationMLSData in
8e92789

ProposalAction ->
Maybe UpdatePath ->
Sem r ()
processExternalCommit qusr mSenderClient lconv cm epoch groupId action updatePath = withCommitLock groupId epoch $ do
processExternalCommit qusr mSenderClient lconv mlsMeta cm epoch action updatePath = withCommitLock (cnvmlsGroupId mlsMeta) epoch $ do
Copy link
Contributor

Choose a reason for hiding this comment

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

The ConvNotFound error constraint likely isn't needed here either.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Unfortunately because of checkGroup it can't be removed

ProposalAction ->
Sender 'MLSPlainText ->
Commit ->
Sem r [LocalConversationUpdate]
processCommitWithAction qusr senderClient con lconv cm epoch groupId action sender commit =
processCommitWithAction qusr senderClient con lconv mlsMeta cm epoch action sender commit =
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you check if ConvNotFound can be removed from this one too?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Unfortunately it can't because of downstream checkGroup.

@@ -110,9 +110,10 @@ removeClient ::
ClientId ->
Sem r ()
removeClient lc qusr cid = do
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you see if you can change the signature of the function such that you don't need to do for_ in the function? You know you do this only for MLS clients, so it feels a bit awkward to have to check if this is an MLS conversation.

I think you could pass in ConversationMLSData and as little as needed from Local Data.Conversation instead of passing in the whole conversation.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Downstream of removeClient is propagateMessage and runMessagePush which require the full conversation object. Maybe we could refactor them as well, but I woudn't want to mix it into this PR

Copy link
Contributor Author

@smatting smatting Nov 24, 2022

Choose a reason for hiding this comment

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

Fair point about inlining the for_ part into removeUser itself. Did this is acf5d67bb0fc9e61753e927bb8f7751377a33c26

@smatting smatting force-pushed the fs-901/preparation-member-clients branch from e2f47c8 to 8e92789 Compare November 24, 2022 17:48
@smatting smatting temporarily deployed to cachix November 24, 2022 17:48 Inactive
@smatting smatting temporarily deployed to cachix November 24, 2022 17:48 Inactive
@smatting smatting temporarily deployed to cachix November 24, 2022 17:59 Inactive
@smatting smatting temporarily deployed to cachix November 24, 2022 17:59 Inactive
@smatting smatting force-pushed the fs-901/preparation-member-clients branch from acf5d67 to d9b8425 Compare November 24, 2022 18:02
@smatting smatting temporarily deployed to cachix November 24, 2022 18:02 Inactive
@smatting smatting temporarily deployed to cachix November 24, 2022 18:02 Inactive
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.

None yet

3 participants