###############################################################################
# Bug#27368735 BINLOG NAME AND POS ARE WRONG IN GROUP_REPLICATION_APPLIER
#               CHANNEL'S ERROR MSGS
# Problem: When group_replication_applier channel's applier thread is facing
#          an error, master_log_name and end_log_pos in the error message
#          are incorrect.
#
# Steps to reproduce:
# ===================
# 0) Test require two servers in the group
# 1) Create a table with a primary key on both servers.
# 2) Have a tuple with key '1' on server2.
# 3) Insert the same tuple on server1 and try to sync on server2.
# 4) Sync (applier thread on server2) will fail because of
#    the duplicate key error.
# 5) Check that the error says master_log_name and end_log_pos as <unknown>
#    instead of displaying wrong values.
# 6) Cleanup (drop table on both servers)
###############################################################################
--source include/only_mts_slave_parallel_workers.inc
--source ../inc/have_group_replication_plugin.inc
--source ../inc/group_replication.inc

--echo #
--echo # Step-1: Initial setup (create table on both servers)
--echo #
--let $rpl_connection_name= server_1
--source include/rpl_connection.inc
CREATE TABLE t1(i INT PRIMARY KEY);
--source include/rpl_sync.inc

--echo #
--echo # Step-2: Insert a tuple on server2 directly without writing
--echo #         into binlog.
--echo #
--let $rpl_connection_name= server_2
--source include/rpl_connection.inc
SET sql_log_bin=0;
INSERT INTO t1 values (1);

--echo #
--echo # Step-3: Add error suppressions which are required
--echo #         for the test to pass.
--echo #
CALL mtr.add_suppression("Could not execute Write_rows event on table test.t1");
CALL mtr.add_suppression("The applier thread execution was aborted. Unable to process more transactions, this member will now leave the group.");
CALL mtr.add_suppression("Fatal error during execution on the Applier process of Group Replication. The server will now leave the group.");
CALL mtr.add_suppression("The server was automatically set into read only mode after an error was detected.");
CALL mtr.add_suppression("Skipping leave operation: concurrent attempt to leave the group is on-going.");
CALL mtr.add_suppression("The slave coordinator and worker threads are stopped");
SET sql_log_bin=1;

--echo #
--echo # Step-4: Insert a tuple on server1
--echo #
--let $rpl_connection_name= server_1
--source include/rpl_connection.inc
INSERT INTO t1 VALUES (1);

--echo #
--echo # Step-5: sync will fail because the same tuple exists on server2
--echo #         (insert on server2 at step-2).
--echo #
--let $rpl_connection_name= server_2
--source include/rpl_connection.inc
--let $group_replication_member_state= ERROR
--source ../inc/gr_wait_for_member_state.inc

--echo #
--echo # Step-6: Grep for the expected error in server log.
--echo #
--let $assert_file= $MYSQLTEST_VARDIR/tmp/gr_applier_error.2.err
--let $assert_count = 1
--let $assert_select = failed executing transaction '.*'; Could not execute Write_rows event on table test.t1; Duplicate entry '1' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY, Error_code: 1062
--let $assert_text = Found the expected error in group_replication_applier channel.
--source include/assert_grep.inc

--echo #
--echo # Step-7: Cleanup (drop table on both servers)
--echo #
--let $rpl_connection_name= server_1
--source include/rpl_connection.inc
DROP TABLE t1;

--echo # Step-7.2: Server_2 entered into 'read_only' mode due to the above error.
--echo #           Sync the above 'drop table' wont work.
--echo #           Reset the slave and 'DROP' the table manually.
--let $rpl_connection_name= server_2
--source include/rpl_connection.inc
--source include/stop_group_replication.inc
RESET SLAVE ALL FOR CHANNEL "group_replication_applier";
DROP TABLE t1;
--source ../inc/group_replication_end.inc