carnagion/norris

A registration bot for the official University of Nottingham Computer Science starters Discord server.

Norris

Norris is the registration bot for the official University of Nottingham Computer Science starters Discord server.

Features

• User registration - Users joining the server must go through a multi-step registration process before they are allowed access to most channels

• Automatic de-registration - Users leaving the server are automatically de-registered

• Nickname requests - Users can request nicknames, which must be approved by a mentor

• Simple configuration - Data is deserialized from a configuration file at startup rather than using hard-coded values

• Robust error handling - Errors and failure cases are handled gracefully, without panics or crashes

• Log files - Errors, warnings, and other notable events are logged to files that are created on a daily basis

• Fully documented - Comprehensive documentation regarding design and setup, intended for future maintainers

Commands

Norris supports the following slash commands:

• /registration add [NAME] [KIND] - Add a user to the registration whitelist (usable by administrators only)

• /registration restart [USER] - Restart a user's registration (usable by mentors and administrators only)

• /registration nuke [ROLE] - Restart the registrations of all users with a particular role, defaulting to all undergraduate and postgraduate students if ROLE is not provided (usable by administrators only)

• /nickname [NAME] - Request a server nickname

• /count undergrads - Report the number of registered and total undergraduate students

• /count postgrads - Report the number of registered and total postgraduate students

User data

Norris only stores the minimum amount of user data required to perform registration, as seen in its database schema.

• Student names and kinds (undergraduate or postgraduate) are obtained from the University via the proper channels.

• Users that join the server have their Discord user ID stored to keep track of their registration state.

• Pronouns and housing information are provided voluntarily by users, can be skipped, and are not stored in the database.

Additionally, access to user data via the database is limited to server administrators only.

Contributors

• Indraneel Mahendrakumar
• Callum Daniel

Credits

Thanks to:

• Joe Sieniawski and the University of Nottingham Computer Science Research Support Team, for providing a database and server to host Norris on
• Ben Flynn, for providing the previous year's codebase, which served as a foundation for the current bot

Frequently asked questions

• Why is it called Norris?

  Who knows? We certainly don't.

norris's Issues

Limit the number of concurrent restarts when nuking, or spawn each restart as a separate task

Currently, when executing /registration nuke, every user's registration is restarted concurrently, on the same tokio task (which is spawned by poise and serenity when handling the command).

However, when restarting the registrations of hundreds of users, the high number of incoming and outgoing Discord websocket requests and database connections, combined with the insufficient database connection limit, leads to the operations being performed inconsistently.

This might be solved in one of three ways:

• Limit the number of concurrent restarts to prevent situations where the database cannot handle the sheer number of connections
• Perform each restart in a separate tokio task, possibly combined with the above, to introduce some leeway for parallelism and avoid excessive load on one task
• Restart registrations sequentially rather that concurrently to provide more predictable and consistent behaviour

Alert when shutting down

Currently, Norris runs forever, with the only way to stop it being to terminate its process (typically using either Ctrl + C or kill). This forcefully interrupts the process, which is fine for Norris' use case, but we lose out on an important opportunity of logging the shutdown time. Knowing when Norris shuts down unexpectedly is important so that potential future bugs can be detected more easily.

Therefore, it would be useful to intercept the shutdown signals SIGINT and SIGTERM (SIGKILL cannot be intercepted) and log shutdown or send a shutdown alert on a channel in Discord, before finally gracefully shutting down.

A possible solution in Rust would involve awaiting on the shutdown signal within a select!. For the Python version, this might require catching a KeyboardInterrupt exception.

• Setup signal handlers in Rust version to send an alert during shutdown (see 569ff08)
• Setup interruption exception handlers in the Python version to send an alert during shutdown

Display current number of students upon welcome

When welcoming new students into the server, it would be nice to inform them how many students registered before them. A line such as You are the [insert number]th student to register! could be included as part of the welcome embed.

The displayed statistic may not be completely accurate, as users leaving the server (and therefore being de-registered) would skew the count. Nevertheless, the feature is not intended to serve an important purpose so this is OK.

This feature was present in the previous year's bot but not in the current implementation (neither in Rust nor Python), and would be a good way for new contributors to familiarise themselves with the project. It is thus left as an exercise to future maintainers :)

Name History

It's named Norris after the dog at a local pub in Nottingham, the boat inn in Lenton :)

Raise the MySQL database connection limit

The MySQL database pool is currently capped at 25 connections.

This is sufficient for everyday normal operations such as registering users, but falls terribly short when performing much larger, connection- and request-intensive operations such as nuking registrations.

The connection limit should therefore be raised to at least 150, as mentioned in the current version of sqlx's documentation.

Nuking registrations is unbearably slow

Executing /registration nuke on approximately 100 users takes an abnormally long period of time to finish, upwards of 3 hours.

During this time period, the following bugs are also observed:

• Any messages relating to registrations appear late and out of order, including registration logs, welcome messages, and DMs sent to users
• Registration cannot progress past a certain point for some users due to a lack of response from interactions such as button clicks
• Some users end up with multiple pronouns or housing roles after registration, without having added or requested for the "extra" roles themselves
• Executing /registration restart results in an interaction failure with no response and nothing restarted

I believe that these bugs are a result of a high number of concurrent requests, poorly managed concurrent tasks, and a limited number of connections. More specifically:

• The MySQL database connection pool maintained by Norris is capped at 25 connections, which is sufficient for ordinary usage but likely too low for large-scale nukes
• Every user's registration is restarted on the same tokio task, concurrently, with no limit to the number of concurrent restarts, possibly leading to excessive load on that task

To rule out other probable causes, such as data races, unexpected external errors, and panics or infinite loops, I consulted log files and cross-checked each entry in the database with the users who have completed the registration process, confirming that registrations are being restarted and completed without losing track of progress or halting midway.

As such, I believe that these concurrency limits (or lack thereof), combined with the sheer number of messages and interactions to send and process, are the most likely causes of the abysmal command execution time and subsequent bugs.

I think the following steps would be a good starting point in fixing these issues:

• #3
• #4

Once the above tasks have been completed, registration nuking should be thoroughly tested again, to ensure that it is capable of withstanding high loads.