This page covers known operational edge cases and current handling behavior. It is organized by failure subsystem so admins can triage faster.

Key safeguards:

• Missing Core dependency: startup error banner and plugin remains limited.
• Save backend connection failure: fallback to SQLite when non-SQLite fails.
• Conversion mode: joining players are disallowed during conversion.
• Loader lock handling: locked accounts trigger delayed/forced load logic.

• Dependency and startup subsystem
• Backend connection subsystem
• Conversion and upgrade gating subsystem
• Account lock and load subsystem
• Logging and diagnostics subsystem

Relevant keys:

• Bank.Save.Lock.Time
• Bank.Save.Load.Delay
• Convert.Confirm
• Upgrade.*
• Bank.Log.*

Triage order:

1. Check startup dependency errors.
2. Check backend connection and fallback logs.
3. Check conversion/upgrade flags.
4. Check lock mode and delayed-load behavior.

• /bank admin lock <player> <true/false>
• /bank admin fix usernames
• /bank admin debug item

Error-path commands are mostly admin gated.

Lock persistence can use boolean lock rows or time-based lock rows depending on save lock mode.

• Fast server-switch player sees lock message; account unlocks after configured lock behavior window.
• MySQL outage at startup results in automatic SQLite fallback.

• Players remain locked after crash: inspect lock tables and use admin lock tools.
• Repeated conversion kicks: verify convert.yml and upgrade.yml flags are false after conversion.
• Repeating SQLite fallback in production: treat as backend incident and keep server in maintenance mode until primary backend is stable.

• Storage and Persistence
• Admin Operations and Troubleshooting