Diagnose plugin conflicts
Reproduce on staging, check dependencies, and preserve main-thread ownership.
Plugin enable failures
Read the first causal error rather than only follow-up errors. Check Minecraft/Java versions, required dependencies, duplicate JARs, permissions, and plugin data migrations. Match doctor advisories to the author’s supported builds.
Do not remove production plugin data without backup. Reverting database/file migrations can require a matching data snapshot.
Isolate the combination
- Create staging and disable accidental production integrations there.
- Reduce the reproduction to the smallest normal action still causing the problem.
- Test the plugin plus required dependencies, then add others in groups. Split large groups to narrow conflicts.
- Keep workload/config comparable and restart after each change.
- Compare relevant Nusa flags one at a time only when evidence points there.
NMS/reflection/adapter plugins may need a precise build despite preserved public APIs. An advisory by itself is not proof of failure.
AsyncCatcher and CME
AsyncCatcher/ownership errors can indicate access from the wrong thread. ConcurrentModificationException can mean unsafe collection mutation or another bug; inspect the stack with context.
Do not disable AsyncCatcher, spoof primary-thread identity, or move World/Entity/Player mutation to workers. Use the supported main-thread scheduler. Send a minimal reproduction and relevant redacted stack trace to the responsible maintainer/support.
Emergency diagnosis
Read safemode before use: it also bypasses Nusa guards and retains some startup resources. Changed behavior in safemode narrows the search but does not identify one module or certify a plugin. For legitimate rejected input use false-positive checks and a support report.