-
Notifications
You must be signed in to change notification settings - Fork 287
refactor(send_queue): generalize SentRequestKey::Media and DependentQueuedRequestKind::UploadFileWithThumbnail to prepare for MSC4274 gallery uploads #4897
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
Conversation
…ueuedRequestKind::UploadFileWithThumbnail to prepare for MSC4274 gallery uploads Signed-off-by: Johannes Marbach <[email protected]>
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4897 +/- ##
=======================================
Coverage 85.69% 85.70%
=======================================
Files 309 309
Lines 35398 35400 +2
=======================================
+ Hits 30334 30338 +4
+ Misses 5064 5062 -2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
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.
Thanks for the patch.
I believe it would be lovely to add a couple of tests just to ensure the accumulated
field correctly accumulates the media info. Is it doable?
It is slightly tricky because I think currently it can only be tested indirectly through the final event that is being sent. For galleries the code to send the event is still missing, however. I was planning to add it with a separate PR, including tests. I realize this isn't ideal but I'm not sure how to best test it in this PR here. 😕 |
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.
It makes sense to me, thank you. @bnjbvr would you like to take a look too?
Yep, thanks for the ping. |
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.
Thanks! There might be a subtle breaking data format change here, so requesting changes to double-check this with a test, at least.
/// Accumulated list of infos for previously uploaded files and thumbnails | ||
/// if used during a gallery transaction. Otherwise empty. | ||
#[cfg(feature = "unstable-msc4274")] | ||
#[serde(default)] | ||
pub accumulated: Vec<AccumulatedSentMediaInfo>, |
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.
There might be a different possible data scheme here, if I understand correctly:
SentMediaInfo
contains only the vec ofAccumulatedSentMediaInfo
(since a vec can hold the pair for the media, when there's only a single one and no gallery)AccumulatedSentMediaInfo
(maybe renameSingleSentMediaInfo
?) can keep on holding its current fields.
Again, I see this struct SentMediaInfo
is also marked as Serialized/Deserialize
, so maybe what I'm suggesting implies having to a data migration 🥴.
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 think technically this would work, yes. I didn't go for it originally because I wanted to minimize breaking changes and because it felt slightly cleaner to have accumulated
only contain the requests that are actually finished. This way, we only push to accumulated
. If we do it the other way around, we'll need to push or modify the last item depending on what the request is for. Did you have specific advantages of using this variant in mind?
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 only advantage is technical, in that it avoids containing what's effectively another flattened AccumulatedSentMediaInfo
next to the accumulated
vector, and also reduces the number of concepts.
I'm a bit torn, because this is likely a non-trivial change, but on the other hand that might be a nice simplification. Maybe that could be attempted as a follow-up, and we could open an issue to not forget about it?
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.
Yeah, I see the oddness. Sounds good on the issue. I have opened: #4969
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.
Looks good to me, thanks. Approving so that we can merge this as soon as my review comments have been addressed. Any chance we can also include some unit tests relevant to the changes here, or is that not worth it?
/// Accumulated list of infos for previously uploaded files and thumbnails | ||
/// if used during a gallery transaction. Otherwise empty. | ||
#[cfg(feature = "unstable-msc4274")] | ||
#[serde(default)] | ||
pub accumulated: Vec<AccumulatedSentMediaInfo>, |
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 only advantage is technical, in that it avoids containing what's effectively another flattened AccumulatedSentMediaInfo
next to the accumulated
vector, and also reduces the number of concepts.
I'm a bit torn, because this is likely a non-trivial change, but on the other hand that might be a nice simplification. Maybe that could be attempted as a follow-up, and we could open an issue to not forget about it?
// If the parent request was a thumbnail upload, don't add it to the list of | ||
// accumulated medias yet because its dependent file upload is still | ||
// pending. If the parent request was a file upload, we know that both | ||
// the file and its thumbnail (if any) have finished uploading and we | ||
// can add them to the accumulated sent media. |
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.
Super nice comment, thanks!
Co-authored-by: Benjamin Bouvier <[email protected]> Signed-off-by: Johannes Marbach <[email protected]>
…single_dependent_request
Co-authored-by: Benjamin Bouvier <[email protected]> Signed-off-by: Johannes Marbach <[email protected]>
Thanks for the merge! Re the unit tests, I just wanted to say that it's a bit tricky on this PR because most of the changes are just routing new fields through existing APIs but nothing really uses these new fields yet. Therefore, I was planning to add tests in future PRs when the accumulation is actually being used by galleries. |
This was broken out of #4838 and is a preliminary step towards implementing MSC4274.
SentRequestKey::Media
andDependentQueuedRequestKind::UploadFileWithThumbnail
are generalized to allow chaining dependent media uploads and accumulating sent media sources.