Error Handling and Edge Cases

Error Handling and Edge Cases

Overview

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

How It Works

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.

Failure subsystems

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

Configuration

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.

Commands

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

Permissions

Error-path commands are mostly admin gated.

Data and Storage

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

Examples

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

Troubleshooting

• 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.

Related Pages

• Storage and Persistence
• Admin Operations and Troubleshooting