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

Message Failed State #902

Merged
merged 6 commits into from
Jul 16, 2024
Merged

Message Failed State #902

merged 6 commits into from
Jul 16, 2024

Conversation

insipx
Copy link
Contributor

@insipx insipx commented Jul 15, 2024

fixes #671

Mark the optimistic message as FAILED whenever its intent is marked as failed (set_group_intent_error)

added message_id function to StoredGroupIntent that calculates a message_id if the intent is of type SendMessage. On intent fail we can access the message and set it to failed in publish_intents.

Make sure that every possible error case in this method results in the corresponding intent either being marked as TO_PUBLISH or FAILED

Verified that the intent is only returned as failed from publish_intents once retries have been reached. Any other error will leave intent as to_publish.

At some point in the future revisit whether there is a possibility of an infinite loop of intent retries. Maybe we should call increment_intent_publish_attempt_count() wherever we reset an intent to TO_PUBLISH, and just set a really high retry limit, like 10?

Intent retries are limited by 3 in sync_until_intent_resolved and also to 3 in publish_intents.

@insipx insipx requested a review from a team as a code owner July 15, 2024 18:23
/// # Returns
/// Returns [`Option::None`] if [`StoredGroupIntent`] is not [`IntentKind::SendMessage`] or if
/// an error occurs during decoding of intent data for [`IntentKind::SendMessage`].
pub fn message_id(&self) -> Result<Option<Vec<u8>>, IntentError> {
Copy link
Contributor

Choose a reason for hiding this comment

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

My only worry about this refactor is that people are going to use it and decode the proto somewhere else separately to get at the other fields, so we're going to end up doing the same work twice.

message_id sounds like it would be a cheap little operation, but it's actually pretty expensive.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added a comment explaining how that is a bad idea, we should watch out for that but I also am not sure when we would access the contents of a PlainText envelope outside of publish success/failure. It could be worth storing the message_id separately on StoredGroupIntent as an Option which would avoid the problem altogether

@insipx insipx merged commit 8fe95b8 into main Jul 16, 2024
4 checks passed
@insipx insipx deleted the insipx/message-failed-state branch July 16, 2024 18:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Message failed state
2 participants