bans are too persistent #855
Labels
No labels
Bug
Cherry-picking
Database
Dependencies
Difficulty
Easy
Difficulty
Hard
Difficulty
Medium
Documentation
Enhancement
Good first issue
Help wanted
Inherited
Matrix/Administration
Matrix/Appservices
Matrix/Auth
Matrix/Client
Matrix/Core
Matrix/Federation
Matrix/MSC
Matrix/Media
Meta
Meta/Packaging
Priority
Blocking
Priority
High
Priority
Low
Security
Status
Confirmed
Status
Duplicate
Status
Invalid
Status
Needs Investigation
Wont fix
old/ci/cd
old/rust
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: continuwuation/continuwuity#855
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Sometimes, when a user is banned and then unbanned, we don't seem to (receive? validate? allow?) the unban, meaning the ban gets stuck, and and subsequent join attempts fail. Somehow, this even means accepting an invite results in a "you're banned" error.
This is worked around by having a second account join the room to receive the updated state (why dont we get this anyway?)
If no accounts in a room or on the server then we don't receive events from the room - so the state that we have is out of date. I need to look into this more, but it's likely that we should ignore any room state that we already have when trying to join a room from that state
That would make sense if this were a persistent issue, but it isn't. When a membership is changed, we tell the target server even if they aren't in the room, so I'm not too sure how this is happening in the first place
A step through debugger on an instance of this would be helpful
A step-through debugger would probably solve most of our problems 🧌
Travis suggested that https://github.com/matrix-org/synapse/pull/15323 may be related, and it does indeed look like the same thing we're running into (i.e. host not in room with dead state). Mirroring the synapse changes into our own code might fix the issue