[Regression]: XP system causes consistent crashes

[jonbarrow]

Checked Existing

• I have checked the repository for duplicate issues.

What happened?

The XP/level system causes crashes almost 24/7. There seems to be some issue with database locking which just kills everything.

Honestly I'm not even sure why this XP/level system was added here. For starters, this is a moderation bot. An "XP" system for trusting users is not moderation, that's more related to community engagement which is better suited for Bandwidth. Secondly, this whole system was added it seems to give people the ability to post images/files in public channels. Why do we want this? This seems to not really add anything of value

What was the previous functionality?

There was no XP/leveling system

When did this occur?

The XP system was added in #25

Other relevant information. (OPTIONAL)

The stacktrace when the crash happens is:

node:events:497
      throw er; // Unhandled 'error' event
      ^
Error
    at Database.<anonymous> (/home/jonbarrow/Chubby/node_modules/sequelize/lib/dialects/sqlite/query.js:185:27)
    at /home/jonbarrow/Chubby/node_modules/sequelize/lib/dialects/sqlite/query.js:183:50
    at new Promise (<anonymous>)
    at Query.run (/home/jonbarrow/Chubby/node_modules/sequelize/lib/dialects/sqlite/query.js:183:12)
    at /home/jonbarrow/Chubby/node_modules/sequelize/lib/sequelize.js:315:28
    at runNextTicks (node:internal/process/task_queues:60:5)
    at listOnTimeout (node:internal/timers:545:9)
    at process.processTimers (node:internal/timers:519:7)
    at async SQLiteQueryInterface.insert (/home/jonbarrow/Chubby/node_modules/sequelize/lib/dialects/abstract/query-interface.js:308:21)
    at async User.save (/home/jonbarrow/Chubby/node_modules/sequelize/lib/model.js:2490:35)
Emitted 'error' event on Client instance at:
    at emitUnhandledRejectionOrErr (node:events:402:10)
    at process.processTicksAndRejections (node:internal/process/task_queues:84:21) {
  name: 'SequelizeTimeoutError',
  parent: [Error: SQLITE_BUSY: database is locked] {
    errno: 5,
    code: 'SQLITE_BUSY',
    sql: 'INSERT INTO `users` (`user_id`,`xp`,`last_xp_message_sent`,`trusted_time_start_date`,`matchmaking_notification_sent`,`createdAt`,`updatedAt`) VALUES ($1,$2,$3,$4,$5,$6,$7);'
  },
  original: [Error: SQLITE_BUSY: database is locked] {
    errno: 5,
    code: 'SQLITE_BUSY',
    sql: 'INSERT INTO `users` (`user_id`,`xp`,`last_xp_message_sent`,`trusted_time_start_date`,`matchmaking_notification_sent`,`createdAt`,`updatedAt`) VALUES ($1,$2,$3,$4,$5,$6,$7);'
  },
  sql: 'INSERT INTO `users` (`user_id`,`xp`,`last_xp_message_sent`,`trusted_time_start_date`,`matchmaking_notification_sent`,`createdAt`,`updatedAt`) VALUES ($1,$2,$3,$4,$5,$6,$7);',
  parameters: {}
}

[MatthewL246]

Could potentially be solved by enabling WAL mode for the sqlite database. This is a database-level change, not an application-level one.