Unable to remove reactions from messages after page refresh.
Steps to reproduce
-
Uploaded an MP4 H265 video file to https://matrix.to/#/!LdFTpgksHpQBBtjOMN:matrix.org/$7z9qoF17VHc08wg2mlG1fRYtfhXbHmhxp-ZNQCXcK-o?via=matrix.org&via=beeper.com.
-
Reacted with an emoji.
-
Attempted to remove the reaction.
Outcome
What did you expect?
I should have been able to.
What happened instead?
I was able to.
-
Refreshed the page.
-
Attempted to remove the reaction.
Outcome
What did you expect?
I should have been able to.
What happened instead?
I was unable to remove it, yet was able to remove others added subsequently:
https://github.com/user-attachments/assets/3d9700f7-9942-4ed8-a618-d6bcd175d04b
Operating system
https://download.fedoraproject.org/pub/fedora/linux/releases/40/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-40-1.14.iso
Browser information
https://fedora.pkgs.org/40/fedora-updates-x86_64/firefox-131.0.3-1.fc40.x86_64.rpm.html
URL for webapp
https://develop.element.io/#/room/!LdFTpgksHpQBBtjOMN:matrix.org
Application version
Element version: 249c0fd1df0a-js-88cf5eb76983 Crypto version: Rust SDK 0.7.2 (517d99b), Vodozemac 0.7.0
Homeserver
https://matrix.org/
Will you send logs?
Yes
Will you send logs?
Yes
Sent:
/rageshakeI'm unable to remove the "O" reaction fromhttps://matrix.to/#/!LdFTpgksHpQBBtjOMN:matrix.org/$7z9qoF17VHc08wg2mlG1fRYtfhXbHmhxp-ZNQCXcK-o?via=matrix.org&via=beeper.com.
This is really weird. From the logs, it looks like eventShouldLiveIn(redaction_event) is returning false.
Maybe try Clear cache and reload in Settings ~> Help & About.
Maybe try Clear cache and reload in Settings ~> Help & About.
@MidhunSureshR, unfortunately, I've confirmed that it's either a problem with the server or a module common to all clients, since I have been able to reproduce this on f-droid.org/repo/im.vector.app_40106204.apk (of element-hq/element-android), too.
However, looking back at the referenced message, the emojis in question appear to have finally been redacted. Perhaps the undermentioned message source data shall tell you something of value (if I've selected the correct message – the highlight isn't very obvious):
{ "content": { "body": "1000009396.mp4", "info": { "duration": 71077, "h": 720, "mimetype": "video/mp4", "size": 28260134, "thumbnail_info": { "h": 1080, "mimetype": "image/jpeg", "size": 280933, "w": 1920 }, "thumbnail_url": "mxc://matrix.org/UwUKTRfOHkZaYjEbFNdShHKd", "w": 1280 }, "msgtype": "m.video", "url": "mxc://matrix.org/ubcJFQyLqcXmyqqNzlsLiSfX" }, "origin_server_ts": 1729422562766, "room_id": "!LdFTpgksHpQBBtjOMN:matrix.org", "sender": "@rokejulianlockhart:matrix.org", "type": "m.room.message", "unsigned": { "membership": "join", "age": 1057522431, "m.relations": { "m.thread": { "latest_event": { "content": { "body": "Re_ Submission from Service Request Form_ Black display on FW16 after inputting LUKS password. 2024-10-20T12_29_59+01_00.eml", "info": { "mimetype": "message/rfc822", "size": 46349 }, "m.mentions": {}, "m.relates_to": { "event_id": "$7z9qoF17VHc08wg2mlG1fRYtfhXbHmhxp-ZNQCXcK-o", "is_falling_back": true, "m.in_reply_to": { "event_id": "$MMpRrrlL2AXm0M0gjb45KTwV8rnnJsW0pQdZZ8qQRdw" }, "rel_type": "m.thread" }, "msgtype": "m.file", "url": "mxc://matrix.org/XvClKBoPaUVNvHpCZvSrvHAg" }, "origin_server_ts": 1729424463627, "room_id": "!LdFTpgksHpQBBtjOMN:matrix.org", "sender": "@rokejulianlockhart:matrix.org", "type": "m.room.message", "unsigned": { "age": 1055621570 }, "event_id": "$GNjxcv9C-MuE2UQ5JaQINVLRD4XQEAaoBcNJjX-nqjM", "user_id": "@rokejulianlockhart:matrix.org", "age": 1055621570 }, "count": 4, "current_user_participated": true } } }, "event_id": "$7z9qoF17VHc08wg2mlG1fRYtfhXbHmhxp-ZNQCXcK-o", "user_id": "@rokejulianlockhart:matrix.org", "age": 1057516185 }
My consequent estimate is that the matrix.org server is taking an inordinate amount of time to process these requests. Perhaps, it is a matter of prioritisation, considering that emoji reactions should be fairly inconsequential in comparison to ensuring that messages are sent on-time...?
either a client-source or server issue, since I have been able to reproduce this on f-droid.org/repo/im.vector.app_40106204.apk of element-hq/element-android too.
Element Web & Element Desktop share no code other than encryption code which is unrelated to reactions/redactions so this is a server issue
https://github.com/element-hq/element-web/issues/28249#issuecomment-2452303316
@t3chguy, I'd say that closing this seems short-sighted - surely the client should at least display a reportable error when this fails? I know that Discord does when it's unable to add or remove a reaction.
Irrespective, has anyone any idea how to report this to Matrix if so, considering that it's the recommended homeserver?
@RokeJulianLockhart the server says the redaction is successful with a 200 OK, so is not something a client can reliably detect or deal with.
https://github.com/element-hq/element-web/issues/28249#issuecomment-2452332498
@t3chguy, I realize that I'm no Matrix developer, but if the client continues to display the reaction after I tap or click it to redact it, then surely at some level the client understands that the event was not yet ratified by the server?
I estimate that if whatever informs it that the emoji should remain continues to signal so despite the fact that the 200 OK signal has been received by the client, then surely the client should be able to ascertain that the reaction should no longer be displayed?
@RokeJulianLockhart sure, you could have defensive code like that, and contributions welcome, but having to assume the Server may not be spec compliant will probably double the codebase in size if we have to handle most edge cases which may occur when dealing with non-compliant or buggy servers.
https://github.com/element-hq/element-web/issues/28249#issuecomment-2452332498
@t3chguy, I have reported this to matrix-org/matrix.org/issues/2553. Many thanks.
@t3chguy, per matrix-org/matrix.org/issues/2553#issuecomment-3347665805, can this be re-closed as a duplicate of matrix-org/matrix.org/issues/2553? It'll assist someone, who discovers this issue first, to ascertain what path to take to its most recent replacement.