From 5eeef4009d52455c44b607e852cb23fbb6e84c99 Mon Sep 17 00:00:00 2001 From: Hemant Dangi Date: Wed, 27 May 2026 17:10:53 +0530 Subject: [PATCH] MDEV-38843: BF applier failed on a node causing complete Cluster lockup log_dummy_write_set() is what releases commit order through commit_order_leave() - which hands the apply error to the provider to drive the inconsistency vote - and advances the storage engine checkpoint. Skipping it on a rollback error leaves the seqno stuck in commit order so all following appliers block on commit_order_enter, and the node silently locks the cluster while staying in the primary component. Always call log_dummy_write_set() on the apply-error path, regardless of the rollback result. The rollback result is still folded into ret so it is not lost. --- src/server_state.cpp | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/src/server_state.cpp b/src/server_state.cpp index 01f7d3e..6045b42 100644 --- a/src/server_state.cpp +++ b/src/server_state.cpp @@ -340,10 +340,17 @@ static int apply_write_set(wsrep::server_state& server_state, } else { - ret = high_priority_service.rollback(ws_handle, ws_meta); - ret = ret || (high_priority_service.after_apply(), 0); - ret = ret || high_priority_service.log_dummy_write_set( - ws_handle, ws_meta, err); + // Always log a dummy write set, even on rollback failure: it + // releases commit order (drives the inconsistency vote) and + // advances the SE checkpoint. The rollback result is still + // propagated into ret. + int const rollback_ret( + high_priority_service.rollback(ws_handle, ws_meta)); + high_priority_service.after_apply(); + int const dummy_ret( + high_priority_service.log_dummy_write_set( + ws_handle, ws_meta, err)); + ret = rollback_ret || dummy_ret; ret = resolve_return_error(err.size() > 0, ret, apply_err); } }