matrix-appservice-gitter
matrix-appservice-gitter copied to clipboard
matrix-org
Have Matrix-side ghosts "leave" the room when required
I.e. when real Gitter-side users do. I believe we get these member events down the gitter event stream; we just have to remember to turn them into m.room.member events.
Also on startup we should do a full membership comparison between the two sides, and remove any ghosts that shouldn't be there any more, in case gitter users departed while we weren't looking (e.g. over a restart)
Commit 8741632 now removes matrix-side ghosts when the real gitter user leaves the room. Still remaining is startup-time cleanup code.
Code now sitting live has an admin command to request a cleanup of one room. I've run that on #matrix-dev and it seems to work fine. I'll push it onto a few other big cases tomorrow then run it in a loop over all the rooms
Found a huge problem - gitter's room.users() only returns 100 users at a time. Had to add some looping code using the skip argument, with a bit of overlap to try to avoid the otherwise-race condition if users join/leave while we iterate. It's not perfect but seems to be OK enough in practice. Have now cleaned up neovim/neovim and rust-lang/rust. I think I'll do a loop of all of the rooms tomorrow.
That's now running live, cleaning up all the should-have-departed-already users across all rooms. It's heavily rate-limited on the gitter API side, so I expect it will be an hour or so yet before it finishes.
That's now run with success. The only remaining task is to work out how to get the bridge to run this check automatically on startup, to bridge across any users who left while it was offline.
The actual query code takes quite a while to run, because of rate-limiting over the "users" pagination, so I'm a little loathe to just run that on startup every time. I may play with it first to see what sort of rate we're allowed by gitter.
According to gitterHQ/api, we're allowed 100 calls/minute. Giving a safety margin of 5, I've made that 95 calls/minute and tidied up the rate-limiting logic to apply globally to the bridge. It now takes about 10 minutes to do that initial sweep.
Perhaps now it's good enough to run every startup. Though I still wonder if there's timeline data we can use out of gitter instead, for this