How to Fix E423 Error Code?

Stage	Troubleshooting Area	What to Verify	Recommended Action	Expected Outcome	When to Escalate
1	Confirm the HTTP status	Verify that the response is HTTP status code 423 Locked, rather than a client-side message with a similar number.	Inspect the browser network panel or capture the response headers with an HTTP diagnostic tool. Record the request method, target path, response body, and timestamp.	Accurate diagnosis The issue is confirmed as a resource-lock condition.	Escalate if the application displays E423 but the server actually returns a different status code.
2	Check for an active lock	Determine whether the requested file, record, folder, or document is currently locked by another session or process.	Close duplicate editing sessions, end abandoned sessions, and wait for a legitimate operation to finish before retrying the request.	Lock released The request completes without returning 423.	Escalate if the resource remains locked after all known sessions have been closed.
3	Refresh authentication and session state	Look for an expired login session, stale cookie, outdated access token, or a second session using the same resource.	Sign out, clear the relevant session data, sign in again, and retry the operation once. Avoid repeatedly submitting the same write request.	Session synchronized A stale client state is removed.	Escalate when a newly authenticated session receives 423 consistently.
4	Inspect WebDAV lock details	For WebDAV resources, review lock metadata such as the lock token, owner, scope, timeout, and depth.	Use the appropriate WebDAV discovery request to identify the lock, then submit an authorized unlock request with the valid lock token. Do not remove a lock that belongs to an active user.	Controlled unlock The resource becomes writable without bypassing access controls.	Escalate if the lock owner or lock token cannot be identified.
5	Review server and application logs	Compare the request timestamp with access logs, application logs, database logs, and background-job records.	Search for lock acquisition, lock renewal, timeout, transaction rollback, deadlock, and failed cleanup events. Correlate the request ID across services.	Root cause isolated The source of the persistent lock is narrowed down.	Escalate when logs show repeated lock creation or failed cleanup.
6	Check interrupted operations	Identify uploads, edits, synchronization jobs, imports, or transactions interrupted by a timeout, network failure, restart, or abrupt client closure.	Confirm that no process is still writing to the resource. Restart only the affected worker or job after validating that partial data can be safely recovered.	Safe recovery The orphaned operation is completed, rolled back, or cleaned up.	Escalate before deleting temporary data or force-releasing a lock.
7	Validate permissions and lock ownership	Confirm that the current account has permission to modify the resource and, where applicable, permission to unlock it.	Review resource ownership, access-control rules, delegated permissions, and service-account scopes. Correct authorization rather than bypassing the lock mechanism.	Authorized access The operation follows the server's locking policy.	Escalate if permissions appear correct but the server rejects a valid lock operation.
8	Test proxies, caches, and gateways	Compare direct and routed requests, including response headers, request IDs, and any gateway-specific behavior.	Bypass an intermediate cache or gateway only in a controlled test environment. Confirm that the 423 response originates from the authoritative server.	Correct response source Intermediary behavior is ruled in or out.	Escalate to the infrastructure team if different network paths return inconsistent lock states.
9	Investigate database or distributed locks	Look for database row locks, advisory locks, distributed-lock records, lease expiration problems, and clock differences between nodes.	Review transaction duration, lock wait timeouts, lease renewal, node health, and time synchronization. Release stale locks only through the system's supported administrative procedure.	Distributed state repaired Lock ownership and expiration behave consistently across nodes.	Escalate immediately if manual database changes would be required.
10	Retest with a controlled request	Verify the same resource, method, account, and request conditions that originally produced E423.	Retry once with a fresh request, then test a read-only operation and a separate resource to determine whether the problem is resource-specific or system-wide.	Issue verified The fix is confirmed without creating duplicate writes.	Escalate if multiple unrelated resources return 423.
11	Preserve evidence for support	Collect the exact timestamp, affected resource identifier, request ID, status headers, sanitized logs, lock token details, and reproduction steps.	Remove passwords, access tokens, personal data, and confidential content. Provide the sanitized evidence to the system administrator or application owner.	Actionable case Support can reproduce and trace the failure.	Escalate when the lock returns after a documented cleanup or when data integrity is at risk.