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

Timeline: Extend UtdCause with new reason codes #4126

Merged
merged 7 commits into from
Oct 23, 2024

Conversation

richvdh
Copy link
Member

@richvdh richvdh commented Oct 15, 2024

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 with matrix_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 the UtdCause which is derived from the decryption failure.

Part of #4048.
Based on #4070.

@richvdh richvdh changed the title Add unable_to_decrypt_info to EncryptedEvent WIP: Add unable_to_decrypt_info to EncryptedEvent Oct 15, 2024
@richvdh richvdh force-pushed the rav/utds_in_timeline_item_content branch from 563d51b to 4282f40 Compare October 15, 2024 13:22
Copy link

codecov bot commented Oct 15, 2024

Codecov Report

Attention: Patch coverage is 80.95238% with 8 lines in your changes missing coverage. Please review.

Project coverage is 84.83%. Comparing base (3887c10) to head (f578f26).
Report is 18 commits behind head on main.

Files with missing lines Patch % Lines
...rates/matrix-sdk-ui/src/timeline/controller/mod.rs 66.66% 3 Missing ⚠️
...tes/matrix-sdk-ui/src/timeline/controller/state.rs 70.00% 3 Missing ⚠️
crates/matrix-sdk-ui/src/timeline/event_handler.rs 83.33% 2 Missing ⚠️
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.
📢 Have feedback on the report? Share it here.

@richvdh richvdh force-pushed the rav/utds_in_timeline_item_content branch 9 times, most recently from 4118003 to 61b7d76 Compare October 17, 2024 21:34
@richvdh richvdh changed the title WIP: Add unable_to_decrypt_info to EncryptedEvent Timeline: Extend UtdCause with new reason codes Oct 17, 2024
@richvdh richvdh force-pushed the rav/utds_in_timeline_item_content branch from 4bd94a2 to efc6909 Compare October 21, 2024 11:53
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`.
@richvdh richvdh force-pushed the rav/utds_in_timeline_item_content branch from efc6909 to 3c2eda2 Compare October 21, 2024 17:03
@richvdh richvdh marked this pull request as ready for review October 21, 2024 17:38
@richvdh richvdh requested review from a team as code owners October 21, 2024 17:38
@richvdh richvdh requested review from andybalaam and removed request for a team October 21, 2024 17:38
Copy link
Member

@andybalaam andybalaam left a 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(
Copy link
Member

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_

Copy link
Member Author

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

Copy link
Member

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

done in 983c436

Comment on lines +198 to +213
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(),
}
}
}
Copy link
Member

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…

Copy link
Member Author

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 with kind: Decrypted, in which case ev.original_content() here will be the decrypted event, and we hit the `Some(content) case on line 214
  • a [Sync]TimelineEvent with kind: UnableToDecrypt, in which case ev.original_content() here will be the encrypted event and unable_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.

Copy link
Member

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.

@richvdh richvdh force-pushed the rav/utds_in_timeline_item_content branch from 983c436 to f578f26 Compare October 23, 2024 08:11
@richvdh richvdh merged commit 3291a42 into main Oct 23, 2024
40 checks passed
@richvdh richvdh deleted the rav/utds_in_timeline_item_content branch October 23, 2024 08:44
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.

3 participants