Failed requests due to permissioning errors successfully replicated in Galera Cluster

Hi MariaDB Team,

during restore of a database on a MariaDB Galera cluster running 10.11.11, I ran into a permissioning problem when restoring views with

DEFINER=`UserX`@`192.168.1.1` SQL SECURITY INVOKER

as the user used fore restore ( GRANT ALL PRIVILEGES ON `DATABASE`.* TO `restoreuser`@`127.0.0.1` IDENTIFIED BY 'restore'; ) was missing the SUPER right. As a consequence, the request failed on the node used for restore. So far, so good.

But as it seems, only on that node the SUPER right was required, as the other nodes didn’t cancel the request but reported success, voting the node I used to restore out of the cluster:

2026-05-04 14:06:36 0 [Note] WSREP: Member 2(node1.local) initiates vote on c0521625-d641-11ee-b094-3ffbcb5324dd:396777218,95b404b3d0011e53: Error_code: 1227;
2026-05-04 14:06:36 0 [Note] WSREP: Votes over c0521625-d641-11ee-b094-3ffbcb5324dd:396777218:
95b404b3d0011e53: 1/3
Waiting for more votes.
2026-05-04 14:06:36 0 [Note] WSREP: Member 0(node2.local) responds to vote on c0521625-d641-11ee-b094-3ffbcb5324dd:396777218,0000000000000000: Success
2026-05-04 14:06:36 0 [Note] WSREP: Votes over c0521625-d641-11ee-b094-3ffbcb5324dd:396777218:
0000000000000000: 1/3
95b404b3d0011e53: 1/3
Waiting for more votes.
2026-05-04 14:06:36 0 [Note] WSREP: Member 1(node3.local) responds to vote on c0521625-d641-11ee-b094-3ffbcb5324dd:396777218,0000000000000000: Success
2026-05-04 14:06:36 0 [Note] WSREP: Votes over c0521625-d641-11ee-b094-3ffbcb5324dd:396777218:
0000000000000000: 2/3
95b404b3d0011e53: 1/3
Winner: 0000000000000000
2026-05-04 14:06:36 489592 [ERROR] WSREP: Inconsistency detected: Inconsistent by consensus on c0521625-d641-11ee-b094-3ffbcb5324dd:396777218
at /home/buildbot/buildbot/build/galera/src/replicator_smm.cpp:process_apply_error():1342
2026-05-04 14:06:36 489592 [Note] WSREP: Closing send monitor...
2026-05-04 14:06:36 489592 [Note] WSREP: Closed send monitor.
2026-05-04 14:06:36 489592 [Note] WSREP: gcomm: terminating thread
2026-05-04 14:06:36 489592 [Note] WSREP: gcomm: joining thread
2026-05-04 14:06:36 489592 [Note] WSREP: gcomm: closing backend
2026-05-04 14:06:36 489592 [Note] WSREP: view(view_id(NON_PRIM,47a07689-baaf,589) memb { …

I guess this happens, as the wsrep applier threads are running as ‘system user’ and therefore have the all privileges (incl. SUPER, ect …). But, if a request has not the proper permissions to be executed, why replicating in the first place? Shouldn’t permission checking be done before replication/adding request to BinLog? (Or did I miss something?)