User management

How the THG Community bot registers members in PostgreSQL on every command.

The bot makes sure everyone who uses it has a row in the database. Members never sign up: registration happens before their command runs.

How it works

1. A member runs a slash command, presses a button or submits a form.
2. A member on the shared blacklist is refused first, so a refused interaction creates no row. Bots are skipped too, or every bot that triggered an interaction would get a row.
3. The member’s Discord username is fetched by their Discord id. If they have no row yet, one is created with that name. If the name changed since, the row is updated.
4. The command runs and can rely on the row existing.

Every startup also re-fetches the username of every stored member in the background and saves the ones that changed. That keeps names current for members who have not used the bot in a while. It also gives the real name to rows that only had the Discord id as a placeholder, such as rows from the one-time import of TriBridge’s old files. A deleted Discord account keeps its last known name.

Database model

model User {
  id        String   @id @default(uuid())
  discordId String   @unique
  username  String
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
  // relations: MinecraftLink, FeatureRequest
}

Other tables relate to the internal User.id, not to the Discord id.

Key functions

• ensureUserExists(discordId) fetches the username, creates or updates the row and returns it.
• getUserByDiscordId(discordId) returns the row without creating one.

Error handling

A database error is logged and passed on. The command does not run, and the member gets an error reply instead of a command that silently does nothing.