Closed LorenDB closed 1 year ago
This again has the problem as your original PR. You are yeeting the original content into the ether and no future update will be able to read the message until it was cleared from the cache. I would really prefer to not do that :3
Oh, you want the original JSON to be stored in the unknown event?
That's what we do for the other unknown event, because it enables us to persist it properly and then in an update show the message appropriately :3
Mhm, that didn't cross my mind when I wrote this. I think that is a good idea though. I'll get it worked up shortly.
I said that multiple times, lol. Also the reason why I said to just do the duck typing in Nheko, but I guess this is fine. :3
Well, I would have done this in nheko, but I felt like it might be a good idea to make mtxclient follow the spec in this case.
Well, tests are failing now :)
Patch coverage: 78.26
% and project coverage change: +0.13
:tada:
Comparison is base (
31f2af6
) 72.33% compared to head (4c1a366
) 72.47%.
:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
Tests are now passing :tada:
Hm, I guess the Invalid is fine, since it is a msgtype, although I still need to check, if this is added to all paths correctly. Could you add some test cases for Invalid?
There, I added a test. I have no idea if that qualifies as enough testing, but it's a start :D
@labhub new-pipeline
ty!
According to the spec, all
m.room.message
events must have a fallbackbody
property that can be displayed. This PR aims to implement this behavior by creating a specialized Unknown type for messages instead of turningm.room.message
events into events that are completely unknown.I literally couldn't be bothered to figure out how to use a custom mtxclient build with nheko, so I haven't put this in nheko yet, but it should pass all the tests.