Skip to main content

Reload & Validation

EasyMenu 7 includes a robust, atomic /menu reload pipeline designed to reload configurations live without risking runtime corruption.

The Atomic Reload Process​

When /menu reload is executed, EasyMenu builds a fully detached reload candidate in memory without modifying the active runtime:

/menu reload triggered
  ↓
1. Background async YAML loading and parsing
2. Intra-menu validation (ID/slot uniqueness, materials, actions)
3. Cross-menu validation (verifies open-menu target existences)
4. Dynamic command planning (detects collisions with other plugins)
  ↓
All checks pass -> Atomic Commit

:::tip Rollback Guarantee If even a single error (ERROR) is detected anywhere in the configuration, the entire candidate is rejected. The previous configuration, active menus, permissions, commands, and cache remain 100% untouched. :::

Diagnostics Log Format​

Parse issues produce structured log messages in your server console:

[shop] menu-items[0].material (diamond) unknown or non-item material: DIMAOND [unknown-material]

Diagnostics include:

  • [shop]: Menu ID
  • menu-items[0].material: YAML path
  • (diamond): Element ID
  • unknown or non-item material: DIMAOND: Human-readable error description
  • [unknown-material]: Stable diagnostic error code

Severity Levels​

  • ERROR: Critical flaws (unknown materials, duplicate slots, bad action syntax, missing menus). Rejects reload.
  • WARNING: Recoverable values (e.g. unknown sound name). Warning is logged and safe fallback is applied while reload proceeds.
  • INFO: Load summaries and diagnostic details.

Stale Interaction Rejection​

The moment a reload commits, callback tokens from menus opened before the reload are invalidated. This prevents players with open menus from executing outdated or modified command definitions.