refactor(send_queue): generalize SentRequestKey::Media and DependentQueuedRequestKind::UploadFileWithThumbnail to prepare for MSC4274 gallery uploads#4897
Conversation
…ueuedRequestKind::UploadFileWithThumbnail to prepare for MSC4274 gallery uploads Signed-off-by: Johannes Marbach <n0-0ne+github@mailbox.org>
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:
|
Hywan
left a comment
There was a problem hiding this comment.
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. 😕 |
|
Yep, thanks for the ping. |
bnjbvr
left a comment
There was a problem hiding this comment.
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.
There might be a different possible data scheme here, if I understand correctly:
SentMediaInfocontains 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.
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.
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.
Yeah, I see the oddness. Sounds good on the issue. I have opened: #4969
bnjbvr
left a comment
There was a problem hiding this comment.
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.
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. |
Co-authored-by: Benjamin Bouvier <benjamin@bouvier.cc> Signed-off-by: Johannes Marbach <n0-0ne+github@mailbox.org>
…single_dependent_request
Co-authored-by: Benjamin Bouvier <benjamin@bouvier.cc> Signed-off-by: Johannes Marbach <n0-0ne+github@mailbox.org>
|
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::MediaandDependentQueuedRequestKind::UploadFileWithThumbnailare generalized to allow chaining dependent media uploads and accumulating sent media sources.