Read media content with [[, not $ - #24
Merged
Merged
Conversation
mx_extract_media_events() threw "$ operator is invalid for atomic vectors" on the first live image it ever saw. `$` partial-matches on a list. An image whose content carries `filename` -- what Element sends for an ordinary photo, and what any client sends when `body` is a caption rather than the file name -- has no exact `file` key, so `content$file` resolved to that filename string. `content$file$hashes` is then `$` on a character vector, which is the error, and `encrypted` would have been TRUE for a cleartext picture had it got that far. Every content field is read with [[ now, and the three that can hold a non-list are checked with is.list() before being indexed into: `file`, `info`, and `m.mentions`. A content that is not an object at all is skipped rather than taken apart. The fixtures did not catch it because none of the cleartext ones carried a `filename`, which is the field that creates the ambiguity. The encrypted fixture does carry one, but it also carries a real `file`, so `$` matched exactly there and nothing was ever wrong. A cleartext-with-filename case is in now, asserting `encrypted` and `file` by value rather than only that the call returns.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
mx_extract_media_events()threw$ operator is invalid for atomic vectorson the first live image it ever saw — a photo posted to a bot room, which came back as no media at all because the consumer wraps the call in atryCatch.Cause
$partial-matches on a list. An image whose content carriesfilename— what Element sends for an ordinary photo, and what any client sends whenbodyis a caption rather than the file name — has no exactfilekey, socontent$fileresolved to that filename string:encrypted = !is.null(ev$content$file)would also have beenTRUEfor a cleartext picture, had it got that far.Fix
Every content field is read with
[[. The three that can hold a non-list are checked withis.list()before being indexed into (file,info,m.mentions), and a content that is not an object at all is skipped rather than taken apart.Why the tests missed it
None of the cleartext fixtures carried a
filename, which is the field that creates the ambiguity. The encrypted fixture does carry one — but it also carries a realfile, so$matched exactly there and nothing was ever wrong.A cleartext-with-filename case is in now, asserting
encryptedandfileby value rather than only that the call returns something. Reverting the fix makes it error.mx_extract_text_events()reads content with$too. I left it alone: its reads arebody,msgtype,m.mentions,m.relates_to, none of which is followed by a second$on a possibly-atomic value, so the same ambiguity cannot produce this failure there. Worth a sweep at some point, not in this fix.239 tests pass.