To test initial functionality, the client attempts to add every single member it sees to the database all over again. Initially, the database handled conflicts by ignoring the provided data, which meant that performance was acceptable. However, now that conflicts are resolved by pushing the member's join date to the join_dates array, there is a very real performance hit (close to 3 minutes for 200k+ members), during which time the database is unusable. As soon as feasible, this needs to be resolved. Potentially need to pull all member and guild IDs, then check against that list before we ask the database to insert another row, or update an existing one.

to not two. Oops

Right now, modMutex is just an object in the main file. While filters can alter and consider it, functions can only read it, not alter it. Ideally, we want both functions and filters to be able to access and alter modMutex. We also probably want to change its name to something more fitting, since it's not moderating access to a single resource like the name implies. I don't know what it is, but it's not a mutex.

package is not working!

Running list of what needs to be done. Will be edited frequently.

• Framework
• Database design
• Command structure
• Filter redesign
• Timed actions infrastructure (db table and handling)