LP #1313962: WSREP reporting conflict state 7 after post commit

**Reported in Launchpad by Marco Tusa last update 17-11-2015 11:16:13

In an architecture having Cluster1 and Cluster2 Geographically distributed.
Having C1Node1 Master of C2Node1, and C2Node1 Master of C1Node (so master master config).

After a real conflict on C2Node1

Note] WSREP: cluster conflict due to high priority abort for threads:
140418 10:46:04 [Note] WSREP: Winning thread:
THD: 21, mode: applier, state: executing, conflict: no conflict, seqno: 327797628
SQL: (null)
140418 10:46:04 [Note] WSREP: Victim thread:
THD: 4, mode: local, state: executing, conflict: cert failure, seqno: -1
SQL: (null)
140418 10:46:04 [Note] WSREP: BF kill (1, seqno: 327797628), victim: (4) trx: 837775944
140418 10:46:04 [Note] WSREP: Aborting query: void
140418 10:46:04 [Note] WSREP: victim 837775944 in state 7
140418 10:46:04 [Warning] Slave SQL: Could not execute Write_rows event on table phl_joomla3.search_responses; Duplicate entry '1109427182' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log binlog.000002, end_log_pos 138968194, Error_code: 1062
140418 10:46:04 [Warning] WSREP: thd 4 seqno 327797637: conflict state 7 after post commit
140418 10:46:04 [Warning] WSREP: thd 4 seqno 327797640: conflict state 7 after post commit
140418 10:46:04 [Warning] Slave SQL: Could not execute Write_rows event on table phl_joomla3.search_responses; Duplicate entry '1109427188' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log binlog.000002, end_log_pos 138969383, Error_code: 1062

WSREP continue to report :
[Warning] WSREP: thd 4 seqno 335847121: conflict state 7 after post commit

For ever.

To stop the message Slave SQL thread must be stop/start.

Message comes from wsrep_hton.cc
line 470 -497
...
if (thd->wsrep_conflict_state != NO_CONFLICT)
{
WSREP_WARN("thd %lu seqno %lld: conflict state %d after post commit",
thd->thread_id,
(long long)thd->wsrep_trx_seqno,
thd->wsrep_conflict_state);
}
...

In short it seems that the status wsrep_conflict_state once set is not correctly change after resolution of the conflict.

I had a chat with Teemu and he asked me to open the bug report.