From 2ef12cab420786da6c16d0b6d05386b6bbb90f3c Mon Sep 17 00:00:00 2001
From: Andrei <andrei.elkin@mariadb.com>
Date: Tue, 18 Jan 2022 19:56:43 +0200
Subject: [PATCH] MDEV-27536 invalid BINLOG_BASE64_EVENT and assertion
 Diagnostics_area:: !is_set()

The assert was caused by an error of XA transaction that had
BINLOG 'base64_string' statement.
The statement failed because of lack of checking whether the encoded
replication event was handled by the slave applier thread.
If it's not the slave applier no error should be generated, but it was
in this case, see a test added.

Fixed along with the idea borrowed the upstream to introduce a check
of which applier executes the replication event and do not
report any error if the applier is a regular server client.
---
 .../suite/binlog/r/binlog_xa_handling.result  | 11 ++++++++
 .../suite/binlog/t/binlog_xa_handling.test    | 28 +++++++++++++++++++
 sql/log_event.cc                              |  3 +-
 3 files changed, 41 insertions(+), 1 deletion(-)
 create mode 100644 mysql-test/suite/binlog/r/binlog_xa_handling.result
 create mode 100644 mysql-test/suite/binlog/t/binlog_xa_handling.test

diff --git a/mysql-test/suite/binlog/r/binlog_xa_handling.result b/mysql-test/suite/binlog/r/binlog_xa_handling.result
new file mode 100644
index 00000000000..980045a08d0
--- /dev/null
+++ b/mysql-test/suite/binlog/r/binlog_xa_handling.result
@@ -0,0 +1,11 @@
+connection default;
+CREATE TABLE t1(f1 int) ENGINE=Innodb;
+XA START '','';
+INSERT INTO t1 VALUES(10);
+BINLOG '
+SOgWTg8BAAAAbgAAAHIAAAAAAAQANS42LjMtbTUtZGVidWctbG9nAAAAAAAAAAAAAAAAAAAAAAAA
+AAAAAAAAAAAAAAAAAABI6BZOEzgNAAgAEgAEBAQEEgAAVgAEGggAAAAICAgCAAAAAAVAYI8=';
+XA END '';
+XA PREPARE '';
+XA ROLLBACK '';
+DROP TABLE t1;
diff --git a/mysql-test/suite/binlog/t/binlog_xa_handling.test b/mysql-test/suite/binlog/t/binlog_xa_handling.test
new file mode 100644
index 00000000000..00e8cfea296
--- /dev/null
+++ b/mysql-test/suite/binlog/t/binlog_xa_handling.test
@@ -0,0 +1,28 @@
+###############################################################################
+# Bug#19928622: ASSERTION `! IS_SET()' FAILED. | ABORT IN
+# DIAGNOSTICS_AREA::SET_OK_STATUS
+#
+# MDEV-27536 Invalid BINLOG_BASE64_EVENT and assertion Diagnostics_area:: !is_set()
+#
+# Test:
+# =====
+# Begin an XA transaction and execte a DML statement so that XA state becomes
+# XA_ACTIVE. Execute the BINLOG command it should not cause any assert.
+# Execution should be successful.
+###############################################################################
+--source include/have_log_bin.inc
+--source include/have_innodb.inc
+
+--connection default
+CREATE TABLE t1(f1 int) ENGINE=Innodb;
+
+XA START '','';
+INSERT INTO t1 VALUES(10);
+BINLOG '
+SOgWTg8BAAAAbgAAAHIAAAAAAAQANS42LjMtbTUtZGVidWctbG9nAAAAAAAAAAAAAAAAAAAAAAAA
+AAAAAAAAAAAAAAAAAABI6BZOEzgNAAgAEgAEBAQEEgAAVgAEGggAAAAICAgCAAAAAAVAYI8=';
+XA END '';
+XA PREPARE '';
+XA ROLLBACK '';
+
+DROP TABLE t1;
diff --git a/sql/log_event.cc b/sql/log_event.cc
index 9108b57fec1..f8373202750 100644
--- a/sql/log_event.cc
+++ b/sql/log_event.cc
@@ -6167,7 +6167,8 @@ int Format_description_log_event::do_apply_event(rpl_group_info *rgi)
     original place when it comes to us; we'll know this by checking
     log_pos ("artificial" events have log_pos == 0).
   */
-  if (!is_artificial_event() && created && thd->transaction.all.ha_list)
+  if (!thd->rli_fake &&
+      !is_artificial_event() && created && thd->transaction.all.ha_list)
   {
     /* This is not an error (XA is safe), just an information */
     rli->report(INFORMATION_LEVEL, 0, NULL,