-
Notifications
You must be signed in to change notification settings - Fork 24
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
Handling of own messages #334
Conversation
// intentionally left blank. | ||
ProcessedMessageContent::StagedCommitMessage(staged_commit) => { | ||
println!("[{}] received staged commit", self.client.account_address()); | ||
openmls_group.merge_staged_commit(provider, *staged_commit)?; |
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 added this line to make my test case handling conflicting messages produce the right errors
|
||
self.publish_intents(&mut conn).await?; | ||
// Skipping a full sync here and instead just firing and forgetting | ||
self.publish_intents(conn).await?; |
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.
To be explicit, what is the reason we can fire-and-forget messages but we can't do the same for other intents?
I'm guessing because OpenMLS only allows us to have one pending commit at a time? Which is not an issue for messages
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.
That's right. Especially with max_past_epochs
we should be able to assume that sending a message will "just work" in almost all cases and not need to be re-queued. There are some edge cases where your local state is way out of sync with the network where it would need a retry, but they should be rare enough I think the trade-off is worth it.
Summary
sync
function to encapsulate publishing, receiving, and post-commit flowsNotes
There are a few error cases that are hard to handle
error
intent status for intents that are impossible (trying to add a member that doesn't exist, trying to add a member already present in the group)Application messages from the wrong epoch. These may actually be fine depending on theWe now don't reject application messages from the wrong epoch. There will be some follow-up work to try and catch application messages that are from outside themax_past_epochs
configmax_past_epochs
window.TODO
merge_pending_commit
gets called it is actually being called on the correct commit