-
Notifications
You must be signed in to change notification settings - Fork 152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Matrix room member lists increasingly diverge from IRC #1838
Comments
I read over this at first, but the logic here matrix-appservice-irc/src/bridge/MemberListSyncer.ts Lines 388 to 393 in 062f3ac
prevents NAMES updates from ever being used after initial sync, whereas they would be very useful to keep everything in sync, especially after netsplits. Or to retry failed leave queue items, when someone joins at a later time
|
matrix-org/node-irc#117 may also be a cause: I still run version 0.34.0 of the bridge, as it is the most recent version where quits, parts and nick changes are bridged properly. |
@jkhsjdhjs ah indeed, already pulled your fix for that into my forked node-irc/matrix-appservice-irc too :) |
This has been an issue for a while now, where the Matrix side of portal rooms has many usernames that joined the IRC channel somewhere in the past, but left a long time ago.
I think this is partly fixed with matrix-org/node-irc#118, as that fixes a bug where the
NAMES
response on re-used clients would always be a superset of the previous listing, so never leaving old users unless the PART/QUIT was directly received.The NAMES response is properly received at bridge startup at least, but that causes it to queue a gigantic amount of
leave
items in theMemberListSyncer
, which don't retry, and which time-out after the default of 30 minutes.In the case of my Libera bridge, around 120 thousand, which it's only able to clear a fraction of them the 30 minutes TTL.
Is there a reason to queue these with a TTL at all?
Also, I think it would be an improvement if
matrix-appservice-bridge
's membership queue would be smarter at cancelling out leave/join's for the same user, if there's already an entry in the queue for them, but maybe that's better directed at that repo instead.EDIT: bridge is globally configured to do member list updates both ways,
initial
andincremental
bothtrue
The text was updated successfully, but these errors were encountered: