-
Notifications
You must be signed in to change notification settings - Fork 454
feat(timeline): send timeline redactions through the send queue #6428
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1 @@ | ||
| [**breaking**] Send redactions issued via `Timeline::redact_event` through the send queue. | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1 @@ | ||
| [**breaking**] Send redactions issued via `Timeline::redact` through the send queue. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -446,6 +446,20 @@ async fn test_redact_message() { | |
|
|
||
| timeline.redact(&first.as_event().unwrap().identifier(), Some("inapprops")).await.unwrap(); | ||
|
|
||
| assert_let_timeout!(Some(timeline_updates) = timeline_stream.next()); | ||
| assert_eq!(timeline_updates.len(), 1); | ||
|
|
||
| assert_let!(VectorDiff::Set { index: 1, value: item } = &timeline_updates[0]); | ||
| assert!(item.as_event().unwrap().content().is_redacted()); | ||
|
|
||
| assert_let_timeout!(Some(timeline_updates) = timeline_stream.next()); | ||
| assert_eq!(timeline_updates.len(), 2); | ||
|
|
||
| assert_let!(VectorDiff::Set { index: 1, value: item } = &timeline_updates[0]); | ||
| assert!(item.as_event().unwrap().content().is_redacted()); | ||
| assert_let!(VectorDiff::Set { index: 1, value: item } = &timeline_updates[1]); | ||
| assert!(item.as_event().unwrap().content().is_redacted()); | ||
|
|
||
|
Comment on lines
+449
to
+462
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm unsure why this is issued three times instead of just twice (local and remote echo of the redaction event). 🤔
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I got curious about this, and found that all three items have the same "unique" ID, 0. The first one looks like this: and the second two are identical (at least in terms of debug formatting) and look like:
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There should indeed be only two (one for the local echo, one after it's been sent by the send queue it should be saved in the event cache). If there was a fake sync mimicking the remote echo, that would explain the third one, but it's not clear here why there's a duplicate one. Wondering if this is a spurious redaction aggregation applied to the redacted item itself, or something like that 👀 If you're interested in digging deeper, that might help avoiding spurious updates.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @Johennes ideally we would work this out before merging, but since I suspect it is unrelated to your change, I could be persuaded to merge without if no-one else on the Rust team objects.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I spent some time looking into this but so far couldn't figure out where the third update comes from, unfortunately. 😕
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am going to defer to @poljar on whether it is ok to merge this without understanding why this code is not behaving how we think it should. |
||
| // Redacting a local event works. | ||
| timeline | ||
| .send(RoomMessageEventContent::text_plain("i will disappear soon").into()) | ||
|
|
@@ -536,6 +550,26 @@ async fn test_redact_local_sent_message() { | |
|
|
||
| // Let's redact the local echo with the remote handle. | ||
| timeline.redact(&event.identifier(), None).await.unwrap(); | ||
|
|
||
| // We receive an update in the timeline from the send queue: the redaction's | ||
| // local echo. | ||
| assert_let_timeout!(Some(timeline_updates) = timeline_stream.next()); | ||
| assert_eq!(timeline_updates.len(), 1); | ||
|
|
||
| assert_let!(VectorDiff::Set { index: 1, value: item } = &timeline_updates[0]); | ||
| let event = item.as_event().unwrap(); | ||
| assert!(event.content().is_redacted()); | ||
|
|
||
| // We receive an update in the timeline from the send queue: the redaction's | ||
| // remote echo. | ||
| assert_let_timeout!(Some(timeline_updates) = timeline_stream.next()); | ||
| assert_eq!(timeline_updates.len(), 1); | ||
|
|
||
| assert_let!(VectorDiff::Set { index: 1, value: item } = &timeline_updates[0]); | ||
| let event = item.as_event().unwrap(); | ||
| assert!(event.content().is_redacted()); | ||
|
|
||
| assert_pending!(timeline_stream); | ||
| } | ||
|
|
||
| #[async_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.
Why is it a breaking change?
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.
The API shape is technically the same. However,
redact.awaitwill no longer mean that the redaction has been sent but instead just that it has been enqueued in the send queue. Callers will have to monitor send queue updates if they're interested in the sending state. That's why I thought it would qualify as a breaking change.