What LOCK_HELD means
LOCK_HELD means the server detected an active lock for a conflicting resource or operation while handling your request. In practice, this usually appears when tick processing or another write path is currently operating on the same war/nation state.
The lock is protective. It prevents two conflicting state mutations from committing at once and preserves deterministic outcomes.
What to do next
The safest response is to wait briefly and retry once active processing clears. If retrying immediately repeats the same code, wait until after the next tick boundary.
Do not spam requests. Repeated retries during the same lock window increase noise without improving success probability.
If this occurs frequently under normal load, capture timestamp, nation/war context, and endpoint so admins can evaluate lock contention patterns. A single LOCK_HELD event is usually normal under contention, especially near tick boundaries. The important signal is sustained repetition across multiple windows.
Where to see tick status (admin)
Admins can inspect tick status and related debug surfaces to confirm whether a run is active or recently completed. Player-facing users should rely on Outcomes timing and retry discipline; admin tick status is mainly for operational confirmation.
When escalating, include the exact reason code (LOCK_HELD) and approximate tick context. That data is far more useful than screenshots alone. Include whether the request was a declare, attack, or cancel action. Operation type helps isolate which lock path is saturated.