-
Notifications
You must be signed in to change notification settings - Fork 258
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
Timeline: Extend UtdCause with new reason codes #4126
Conversation
unable_to_decrypt_info
to EncryptedEvent
unable_to_decrypt_info
to EncryptedEvent
563d51b
to
4282f40
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4126 +/- ##
=======================================
Coverage 84.83% 84.83%
=======================================
Files 269 269
Lines 28826 28842 +16
=======================================
+ Hits 24455 24469 +14
- Misses 4371 4373 +2 ☔ View full report in Codecov by Sentry. |
4118003
to
61b7d76
Compare
unable_to_decrypt_info
to EncryptedEvent
4bd94a2
to
efc6909
Compare
Give `matrix-sdk-ui::event_handler::TimelineEventKind` a new variant which specifically represents events that could not be decrypted.
Stash the reason for the decryption failure in `matrix-sdk-ui::event_handler::TimelineEventKind::UnableToDecrypt`. It's not yet used.
Rather than calling `UtdCause::determine` again when an event is successfully decrypted on retry, re-use the cause we already determined.
Before we do any more work here, give this variant a better name Breaking-Change: `matrix_sdk_crypto::type::events::UtdCause::Membership` has been renamed to `...::SentBeforeWeJoined`.
We'll need this for future changes
efc6909
to
3c2eda2
Compare
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.
One suggestion, but good to go, thanks!
@@ -180,6 +212,24 @@ mod tests { | |||
); | |||
} | |||
|
|||
#[test] | |||
fn if_reason_is_not_missing_key_we_guess_unknown_even_if_membership_is_leave_we_guess_membership( |
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.
We have a convention (which I personally don't like, but do comply with) of test names starting with test_
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.
For me, consistency within a file is more important than the convention for new tests
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.
Then please prefix all the tests names with test_
. This makes it easier to distinguish test functions from non-test functions in LSP searches.
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.
done in 983c436
Some(AnyMessageLikeEventContent::RoomEncrypted(content)) => { | ||
// An event which is still encrypted. | ||
if let Some(unable_to_decrypt_info) = unable_to_decrypt_info { | ||
Self::UnableToDecrypt { content, unable_to_decrypt_info } | ||
} else { | ||
// If we get here, it means that some part of the code has created a | ||
// `SyncTimelineEvent` containing an `m.room.encrypted` event | ||
// without decrypting it. Possibly this means that encryption has not been | ||
// configured. | ||
// We treat it the same as any other message-like event. | ||
Self::Message { | ||
content: AnyMessageLikeEventContent::RoomEncrypted(content), | ||
relations: ev.relations(), | ||
} | ||
} | ||
} |
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 do we handle those two cases separately? The comment doesn't really explain it to me. I'm not quite sure about why we need a new TimelineEventKind
variant just for this…
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'm not quite sure about why we need a new
TimelineEventKind
variant just for this…
Well, the objective here is to convey the unable_to_decrypt_info
that is in the SyncTimelineEvent
or TimelineEvent
to TimelineEventHandler::handle_event
. It seems wrong to just shove another field onto TimelineEventKind::Message
, hence adding a new variant.
Why do we handle those two cases separately? The comment doesn't really explain it to me
If the lower layers have done their jobs correctly, then encrypted events will appear either as:
- a
[Sync]TimelineEvent
withkind: Decrypted
, in which caseev.original_content()
here will be the decrypted event, and we hit the `Some(content) case on line 214 - a
[Sync]TimelineEvent
withkind: UnableToDecrypt
, in which caseev.original_content()
here will be the encrypted event andunable_to_decrypt_info
will be populated, and we hit the case at line 200.
However, the object model still allows for a [Sync]TimelineEvent
with kind: PlainText
whose content is actually a AnyMessageLikeEventContent::RoomEncrypted
, and the second case (lines 203-211) is to deal with that situation. One way that I think it will happen is if the OlmMachine is not correctly set up for some reason (BaseClient::olm_machine
is an Option
which has to be loaded somewhere.) And that's what the comment is trying to say.
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.
Hmm ok, thanks for explaining.
983c436
to
f578f26
Compare
This PR is the final part of the epic of making unable-to-decrypt information available in the timeline. As of #4070, the UTD info is now available in the
[Sync]TimelineEvent
created by the network code: now, we just need to copy that information into the items that are added to the timeline itself.To do this, we add a new variant to
matrix_sdk_ui::event_handler::TimelineEventKind
(not to be confused withmatrix_sdk_common::deserialized_responses::TimelineEventKind
which was recently added in #4082) to hold the relevant data, and then add a bunch of new reason codes to theUtdCause
which is derived from the decryption failure.Part of #4048.
Based on #4070.