public schema. prisma/schema.prisma defines every table there, and migrations create
them. TriBridge keeps its own settings and links in its own tribridge schema in the same database. This bot
neither reads nor writes that schema.
Shared tables
Blacklist
TriBridge writes with plain SQL, so the table’s
id and updatedAt defaults must stay database-side: a
client-side Prisma default would make every bridge insert fail. Both sides cache the list for fifteen seconds
and fail open — an unreadable database blacklists nobody, because failing closed would stop both bots during
an outage.
AdminRole
One list decides who is staff on both bots. TriBridge reads the rows for its Discord server and caches them for
fifteen seconds, so a change here reaches the bridge within that. Both sides fail closed: an unreadable
database makes nobody an admin, because the bridge’s
/send runs any command as a Minecraft account.
A one-time read of MinecraftLink
TriBridge reads MinecraftLink and User exactly once: on the first start of a bridge that has no link list of
its own yet, to start that list from this bot’s links so nobody has to link again. The copy is saved even when
empty, so it never repeats. After that the two link lists are independent, and changing these tables no longer
affects the bridge.
Failure behaviour
This bot treats a database failure as a real error — commands surface it through the error handler. TriBridge loads its settings at startup and falls back to its local snapshots if the database is unreachable.Related
- Account linking — this bot’s links
- TriBridge account linking — the bridge’s own links
- TriBridge blacklist