[REJECTED] Khapra-Cogs

Applications
#1

Discord Name: RaamRaam#0349

GitHub Repository (Must be V3): GitHub - Khapra/Khapra-Cogs: Cogs for Red Discord Bot

Description: I only have one cog at the moment, RoleMemberLimit (Enforces a limit on the maximum number of users a role can be assigned to). I have tested the cog’s functionality and have tried my best to follow all the guidelines. Please let me know if any changes are needed to be made or any further info is required. Thank you.

#2

With the release of 3.5, we are returning to reviewing Cog Creator applications.

Since 3.5 will break every cog that was not specifically coded with it in mind, you need to ensure your repo is updated to be compatible with 3.5 prior to a review being possible. The relevant documentation you will need to update your repo is the following:
-discord.py 2.0 migration: https://discordpy.readthedocs.io/en/v2.2.3/migrating.html
-Red 3.5 breakages: https://docs.discord.red/en/stable/incompatible_changes/3.5.html#incompatible-changes-3-5

Once your repo is updated to support 3.5 on the default branch, please make a comment in this thread to confirm you are once again ready for review. We will only be reviewing repos which comment to confirm 3.5 support, but we will prioritize repos that have been in the queue for a longer period of time first.

If you wish to revoke your application, please comment accordingly so we can clean up the thread. If you need time to make changes, but are actively working on making updates, please also comment accordingly. Applications which do not see any activity within 1 month from today will be closed.

#3

hello, I’ve updated and tested the cog on v3.5. this is to confirm that I’m ready for review.

#4
#5

Thank you for your patience.

Commit hash: 861a5b06d796386605f864dda8ab4eecc7dfaaa8

  • The install instructions in the readme.md file state to use [p]install Khapra-Cogs, instead of [p]cog install Khapra-Cogs, and do not list the step of using [p]repo add.
  • The setup function in your __init__.py file is not awaiting the bot.add_cog call. This method was changed to be asynchronous in Red 3.5 as part of the discord.py version bump, so the cog currently does not get properly added to the bot.
  • [p]rolelimit list looks like it could error if too many limited roles are configured, you might want to add some logic to handle cases where the resulting msg is longer than 2000 characters.
  • The after.remove_roles call in the listener has no bot permissions checking or error handling, so cases where the bot does not have manage_roles or does not have a role higher than the role it is attempting to manage will cause errors to appear in console.
  • The after.send call in the listener does not have error handling for if the user blocked the bot or has direct messages from server members disabled. Additionally, it could be modified to only send one aggregated message after looping through all roles to prevent sending multiple DMs to the same user.
  • The rolememberlimit.py file has an unused setup method. The method in the __init__.py file is the one actually being used by the bot to load the cog, so this method will never be called.
  • If your cog blindly removes a role whenever it is added, it could cause an infinite loop of adding/removing the same role under certain conditions. Say for instance, another cog wants to keep a role always on a user, but your cog wants to remove that role from the user because it exceeds the role member limit. If neither cog is coded to avoid this situation, the role will be repeatedly added and removed from the user, as fast as rate limits will allow, which is API abuse. To prevent this, you would need to do something like cache the roles that you are removing, and choosing to not re-remove a role that was recently removed by the cog, instead opting to do something like log a warning in console that a role could not be removed to prevent an infinite loop.

I will be rejecting this repo based on the requirement of having a set of cogs, or cog, that is complex enough that it is able to show an understanding of a range of common cog practices. While your current cog shows a good understanding of some topics, such as the fact that Config keys are required to be strings, the simple nature of it makes it hard to get a good sense of how you would handle more complex situations. If you’d like more guidelines on what we’re looking for, please refer to the requirements for approved Cog Creators. You can also feel free to submit your repo to the Red 3rd party cog index as an unapproved repo by providing a PR, after the cog is updated to properly support Red 3.5.

1 Like