From 99fbd61bd9d2e54aec7b7152467669683d75054e Mon Sep 17 00:00:00 2001 From: Mihir Kandoi Date: Thu, 2 Jul 2026 13:15:12 +0530 Subject: [PATCH] fix: restrict repost advisory-lock gate to Postgres MariaDB falls back to the existing deadlock-retry path; the advisory-lock serialization from #56697 now applies on Postgres only. Co-Authored-By: Claude Fable 5 --- erpnext/stock/stock_ledger.py | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/erpnext/stock/stock_ledger.py b/erpnext/stock/stock_ledger.py index db5bc5b5f66..229837d5eed 100644 --- a/erpnext/stock/stock_ledger.py +++ b/erpnext/stock/stock_ledger.py @@ -275,10 +275,11 @@ def repost_gate(item_code, warehouse): racing into a lock-order deadlock. Row locks still enforce correctness; this only cuts the deadlock/retry churn. Scope is repost-vs-repost only -- the synchronous repost_current_voucher submit path is deliberately not gated (blocking a submit behind a background repost would be a - worse regression) and keeps relying on the existing deadlock retry. No advisory locks, no gate.""" + worse regression) and keeps relying on the existing deadlock retry. Postgres only: MariaDB + keeps the plain deadlock-retry path.""" # hasattr keeps this a graceful opt-in: on an ERPNext predating frappe.db.advisory_lock, fall # back to no gate rather than raising and marking the Repost Item Valuation permanently Failed. - if frappe.db.db_type in ("postgres", "mariadb") and hasattr(frappe.db, "advisory_lock"): + if frappe.db.db_type == "postgres" and hasattr(frappe.db, "advisory_lock"): # Tuple key: a colon in item_code/warehouse can't collide two distinct pairs onto one lock. return frappe.db.advisory_lock(("stock_repost", item_code, warehouse), timeout=REPOST_LOCK_TIMEOUT) return nullcontext()