File redactions not immediately propagated
Description
I was in a channel which is owned by another homeserver where someone posted bad things. Those bad things were then deleted.
However, the redaction event was not propagated over the federation for over 30 minutes. I am not sure if it still is there, but I am not unblocking the user who sent those messages.
This left multiple users having to see the harmful content.
Steps to reproduce
- Synapse server A.org hosts a channel
- user user:B.org joins a channel
- user:B.org posts an image
- admin:A.org deletes the image/message and bans the account
- Synapse server user random:C.org still sees the redacted messages/images even after 30 minutes
Homeserver
mx.scalie.zone is my homeserver, kde.org is the channel owner, maintained by EMS
Synapse Version
1.116.0, the channel owning homeserver is on 1.115.0 i think
Installation Method
Debian packages from packages.matrix.org
Database
PostgreSQL, single server, no ports
Workers
Single process
Platform
My homeserver uses this: https://www.netcup.com/en/server/vps/vps-1000-g11-12m-iv
Configuration
No response
Relevant log output
Unsure if exactly relevant, but I saw warnings like this where the spammer account is mentioned.
2024-10-03 12:05:42,416 - synapse.handlers.federation_event - 2044 - WARNING - _process_incoming_pdus_in_room_inner-44011-$0Pkscx0uwpmvoVymcgckLzUAhGG0zJlVBVm7KWU9EFs - Soft-failing <FrozenEventV3 event_id=$0Pkscx0uwpmvoVymcgckLzUAhGG0zJlVBVm7KWU9EFs, type=m.room.message, state_key=None, outlier=False> (from 403: User @SPAMMER:SPAMMER_SERVER not in room !gYaaEyvNWxTzXssOmq:kde.org (<FrozenEventV3 event_id=$Gv_JvV4vwnGLV008f6rXFHrJZWtdu0TCKxHx7TBAjdg, type=m.room.member, state_key=@SPAMMER:SPAMMER_SERVER, outlier=False>)) because SPAMMER_SERVER
It just ends there, theres no more after "because SPAMMER_SERVER"
and yes the username is a placeholder there
### Anything else that would be useful to know?
_No response_
You've got this whole "channel owner" thing wrong.
There are no channels, there are rooms.
Rooms do not belong or exist in one server. All servers in the federation have a copy of said room. Matrix is full-mesh, all servers participating in that room federation must send all events to each and every other server.
Now, let's take this fact into your pratical example:
mx.scalie.zone is my homeserver, kde.org is the channel owner, maintained by EMS
Your server, and kde.org is inside said room. Someone, probably NOT from kde.org or your server, sent bad media. Then, someone, maybe from kde.org, maybe not, redacted that message.
This redaction must reach your homeserver for you to see. If your homeserver cannot comunicate with the server from the user sending the redaction, it will take much longer for your server, and for you, to see that redaction (you must get it from another server via backfill)
There are no channels, there are rooms.
Fine, whatever you call it. You know what I meant anyway.
This redaction must reach your homeserver for you to see. If your homeserver cannot comunicate with the server from the user sending the redaction, it will take much longer for your server, and for you, to see that redaction (you must get it from another server via backfill)
What steps can I/we take for this to not happen? What is weird about this is that I saw normal messages just fine, but the deletion didn't happen at all. The users of any homeserver, even the owner of the room, could send a message and I saw them immediately. I was even told that the harmful media was already deleted, yet it wasn't for me.
If I can see messages from admin/moderator of that room, but not the file redactions, why?
Hi and sorry for the delay.
Realistically we don't have the time to investigate this particular occurrence, especially owing to the fact there is not a huge deal of information to go off.
If the problem is just that the redaction is delayed, it could well be a performance problem on your or the sender homeserver (and this would need to be investigated as a specific performance problem, rather than a bug).
As it stands, there isn't a whole lot we can do here, but we do tackle specific problems that prevent redactions from working when we become aware of them (along with enough information to track them down).