Ren and discord.py v2.x Migration

We recently upgraded SFU Anime Club's Discord bot, Ren, to a newer version of Red-DiscordBot and discord.py. This post outlines the motivation and some of the challenges faced during this endeavour.

For the past six years, I have been overseeing the development of SFU Anime Club’s Discord bot, Ren. It is based off the upstream project Red-DiscordBot that uses discord.py to communicate with Discord. The contributors in both repositories do some amazing work to build a foundation for people like us to write our own plugins (otherwise known as cogs). We have had many adventures with Red in the past: I encourage those that are interested to read this post for more details.

Rationale

At the time of this writing, the stable release of Red-DiscordBot was using discord.py v1.7.3. This version of the library connects to Discord on an older API endpoint, namely API v7. The newest and most current Discord API is v10. In mid-November 2022, discord.py v2.1.0 was released with a reminder that v1.7.3 “will stop working by the end of the year”, reminding end users to consider moving to a newer, supported version as soon as possible. An announcement from the discord.py development Discord alerted us about this date.

The notice from Danny, the creator of the discord.py library.

Staying on discord.py v1.7.3 presents us with a couple of issues:

  1. The bot will eventually stop working. In this new year of 2023, Discord plans to decommission API V7 and V8. I haven’t dug too deep into it, but if it’s similar to how other services decommission services, then this will probably be done in phases with a rolling blackout, which will result in intermittent bot outages. This is meant to inform application developers, such as ourselves, to, for a lack of a better term, to “get your shit together and get on the latest version”. Service interruptions are a pretty effective way to garner the attention of an application developer, one which we would like to avoid as much as possible.
  2. We miss out on newer Discord features implemented in the newer API endpoints, such as thread support, slash commands, and menu buttons. Without updating, the bot is unable to interact inside threads, effectively making any custom bot tools, such as word filtering, inoperable within them.

In Red-DiscordBot, the upstream development branch transitioned to discord.py v2 a while back. This would give us a base for migrating cogs, so we decided to explore the changes required for our cogs.

Required work

Rather than waiting for any rolling blackouts that might come, the team decided to incrementally make the required changes to support discord.py v2.x in the last few months, and test it alongside the upstream version of Red-DiscordBot v3.5.0. These changes were committed to our cog repo first. There have been a few occasions where additional changes were needed, like underlying avatar attributes changing because of class model changes, but they have been carefully documented in the discord.py API, so addressing these types of issues were trivial. For the most part, the transition resulted in relatively small diffs for each cog. This allowed us to continue working on fixes to our current cogs, and rebase the discord.py v2.x changes as new changes went into our cogs.

With most of the first party cog conversion work completed, we also needed to re-evaluate the readiness of the third party cogs that we were using. To do this, we scheduled a five hour block of time after work to investigate. Similar to our own cogs, many cog creators have a dpy2 branch where API changes are being made. There were a handful where no such branch was available, for which we created a fork of the cog repo and address API changes. For those interested, we have a Google Doc that outlined the tasks required our third party cog migrations.

During that five hour session, since most of the third party cog verification went more or less according to plan, we migrated our bot to the latest upstream Red-DiscordBot development branch that uses discord.py v2.1.0. We believe that moving forward early before upstream releases a version on discord.py v2.1.0 will allow us to discover issues now and contribute back to upstream projects to the benefit of others where possible, whether it be in the form of filing issues for tracking or creating a pull request to fix issues.

What now?

The current git history of SFUAnime/Ren.

While the majority of the SFU Anime Club’s Rengineers bot team is currently working full time, we still want to make incremental improvements to our code base. Some of the changes planned include:

  • Addressing the few outstanding, lower priority third-party cogs that were not migrated to dpy2, including Casino, Heist, and Invoice.
  • Refactoring the codebase to make our code more testable by separating out business logic from hard-to-unit-test discord.py API calls.
  • Exploring the use of slash commands to see if it would be suitable for some of our commands.
  • Exploring the use of buttons to use for pagination.
  • Verifying that existing cog functionality still work in threads.

This relatively smooth migration process wouldn’t have been possible without the foundation of the upstream Red-DiscordBot repository for making progress on the early adoption of discord.py v2.x. I would also like give a big thank you to Tatsu for dedicating a bunch of his time to help migrate our cogs. Without his help, we wouldn’t have been able to make the switch as smooth as it was.

Finally, if you’re on the SFU Anime Discord and you have some cool ideas for the bot and would like to contribute, please feel free to reach out. One of the goals for having a bot maintained by club members is for anyone to contribute in a meaningful manner.

Until next time,
~Lui

Injabie3
Injabie3

Just some guy on the Internet that writes scuffed code and collects anime figurines.

Articles: 249

Feel free to leave a reply

%d bloggers like this: