Thank you!

Bundling would actually be nice. It would probably help with the bus factor since Legoktm (or any future collaborators) can access both if things happen. We can rename it to something like discordbots if possible, but I have not gotten into accessing the trove project yet so I'm unfamiliar with the technicalities behind it. Let me know if there's anything I can do! And thanks.

Per https://github.com/wikimedia/operations-puppet/blob/ee02ed8031f246dd4f309bb7e83eeb9a8f285f51/modules/profile/manifests/toolforge/redis_sentinel.pp#L79-L80 and https://redis.io/docs/reference/eviction/#eviction-policies, it looks like the Redis for Toolforge instance will start deleting old keys once the maxmemory limit is reached. This is usually fine if applications don't want to use redis as a reliable persistent storage (its advertised as a useful cache service), but it would be a bad thing for this specific tool.

The redis trove database can be named wikiauthbot2 since dashes are discouraged.

loggerdiscordbot is fine by me.

Hmm, looks like Dragonfly is able to outcompete Redis in terms of performance and resource usage. I'm interested in trying that. Not sure if that can be run on trove, but I can set it up on a VPS project myself!

Looks like we're moving forward with Trove, and that would probably need to be associated with a tool on toolforge. I've pre-emptively created one at https://toolsadmin.wikimedia.org/tools/id/logger-discord-bot.

A rough estimate I got from a person hosting the bot themselves is 1-2GB. So I suppose 2 or 3GB would suffice?

Well that was after I manually restarted it.

AFAIK the locale needs to be configured correctly using locale-gen. I just tried installing the language packs, and although I have included language-pack-pt-base in the Aptfile it still errors.

I have migrated the jobs and webservices to kubernetes. This should be resolved now.

What would be the use of an untagged union? It doesn't make sense in the function model.

There is a similar exception I am getting when logging in:

It would be very nice indeed if WebAssembly was the common target.

The main part of this problem is that when converting Wikicode to ImmutableWikicode it tries to parse the title from HTML and stores that. Until this is fixed from parsoid's API side a temporary fix would be to store the original provided title within Wikicode and use that when converting to the immutable one.

Oh huh, yeah. We are describing the same thing here.

Yeah, given that we already have a git repo by reedy, it should be easy to migrate to https://gitlab.wikimedia.org or simply closing/archiving the sourceforge repo and deciding to have future development at GitHub. @Reedy: any opinions?

Occurred to me again, after trying to report someone to AIV, Huggle instantly closed itself. When reopening Huggle to revert, it now reports the error.

So for the software that analyzes past hits, I only needed specific variables (other fields are ignored when parsing the json response) It would be nice if there is some sort of afldetailsprop that allows selecting specific variables such as {add,remov}ed_lines to reduce bandwidth usage.

I have hit this. Query dump is at P31153. Its last dump was "Cannot log in when using MediaWiki\Session\BotPasswordSessionProvider sessions." and then it segfaults.