Local transactions on a Slave don't update GTID's gtid_current_pos after RESET MASTER on Slave (master_use_gtid value is not relevant)

Server A = Master id=10133
Server B = Slave id=20133

{{MASTER_USE_GTID = slave_pos|current_pos }} (not relevant)

Writing transactions on both A and B properly updates the global variable gtid_current_pos on the Slave (B).

If I issue RESET MASTER on the Slave gtid_current_pos on the Slave stops being updated.

I am aware of Kristian's comment on https://jira.mariadb.org/browse/MDEV-10279 but I still am not convinced.

MariaDB [test]> SHOW GLOBAL VARIABLES LIKE 'gtid%';

+------------------------+------------+

| Variable_name          | Value      |

+------------------------+------------+

| gtid_binlog_pos        |            |

| gtid_binlog_state      |            |

| gtid_current_pos       | 0-10133-40 |

| gtid_domain_id         | 0          |

| gtid_ignore_duplicates | OFF        |

| gtid_slave_pos         | 0-10133-40 |

| gtid_strict_mode       | OFF        |

+------------------------+------------+

7 rows in set (0.00 sec)

MariaDB [test]> insert into a values (22);

Query OK, 1 row affected (0.01 sec)

MariaDB [test]> SHOW GLOBAL VARIABLES LIKE 'gtid%';

+------------------------+------------+

| Variable_name          | Value      |

+------------------------+------------+

| gtid_binlog_pos        | 0-20133-1  |

| gtid_binlog_state      | 0-20133-1  |

| gtid_current_pos       | 0-10133-40 |

| gtid_domain_id         | 0          |

| gtid_ignore_duplicates | OFF        |

| gtid_slave_pos         | 0-10133-40 |

| gtid_strict_mode       | OFF        |

+------------------------+------------+

7 rows in set (0.00 sec)

Look what happens when the sequence number of the local transaction becomes higher than the sequence number of the latest transaction applied as Slave (gtid_slave_pos):

Generate ~20 transactions on the Slave

MariaDB [test]> SHOW GLOBAL VARIABLES LIKE 'gtid%';

+------------------------+------------+

| Variable_name          | Value      |

+------------------------+------------+

| gtid_binlog_pos        | 0-20133-23 |

| gtid_binlog_state      | 0-20133-23 |

| gtid_current_pos       | 0-10133-40 |

| gtid_domain_id         | 0          |

| gtid_ignore_duplicates | OFF        |

| gtid_slave_pos         | 0-10133-40 |

| gtid_strict_mode       | OFF        |

+------------------------+------------+

7 rows in set (0.00 sec)

_Generate other ~20 transactions on the Slave _

MariaDB [test]> SHOW GLOBAL VARIABLES LIKE 'gtid%';

+------------------------+------------+

| Variable_name          | Value      |

+------------------------+------------+

| gtid_binlog_pos        | 0-20133-40 |

| gtid_binlog_state      | 0-20133-40 |

| gtid_current_pos       | 0-10133-40 |

| gtid_domain_id         | 0          |

| gtid_ignore_duplicates | OFF        |

| gtid_slave_pos         | 0-10133-40 |

| gtid_strict_mode       | OFF        |

+------------------------+------------+

7 rows in set (0.00 sec)

And one more...

MariaDB [test]> SHOW GLOBAL VARIABLES LIKE 'gtid%';

+------------------------+------------+

| Variable_name          | Value      |

+------------------------+------------+

| gtid_binlog_pos        | 0-20133-41 |

| gtid_binlog_state      | 0-20133-41 |

| gtid_current_pos       | *0-20133-41* | 

| gtid_domain_id         | 0          |

| gtid_ignore_duplicates | OFF        |

| gtid_slave_pos         | 0-10133-40 |

| gtid_strict_mode       | OFF        |

+------------------------+------------+

7 rows in set (0.01 sec)

Note gtid_current_pos changing value now from 0-10133-40 to 0-20133-41

To be said that clearing gtid_slave_pos "solves" that but of course it has its consequences.

From what I see due to the fact that the locally generated transaction has a lower sequence number it's basically ignored until the sequence number surpasses the one contained in gtid_slave_pos

I don't know if this is an intended behaviour.

Manual page says: https://mariadb.com/kb/en/library/gtid/#gtid_current_pos

[1]This variable is the GTID of the last change to the database for each replication domain. Such changes can either be master events (ie. local changes made by user or application), or replicated events originating from another master server.

[2]For each replication domain, if the server ID of the corresponding GTID in @@gtid_binlog_pos is equal to the servers own server_id, and the sequence number is higher than the corresponding GTID in @@gtid_slave_pos, then the GTID from @@gtid_binlog_pos will be used. Otherwise the GTID from @@gtid_slave_pos will be used for that domain.

[3]Thus, @@gtid_current_pos contains the most recent GTID executed on the server, whether this was done as a master or as a slave. This value is used as the starting point of replication when a slave is configured with CHANGE MASTER TO master_use_gtid=current_pos.

[4]The value is read-only, but it is updated whenever a DML or DDL statement is written to the binary log and/or replicated by a slave thread.

If you read paragraph [2] explains exactly the behaviour, and so it seems documented (even if not clear to me the rationale):
"and the sequence number is higher than the corresponding GTID in @@gtid_slave_pos" ,

but paragraph [3] says:
"Thus, @@gtid_current_pos contains the most recent GTID executed on the server, whether this was done as a master or as a slave."

Which is not true, gtid_current_pos does not contain the most recent GTID executed on the server, at least not until the sequence number is greater than the one in gtid_slave_pos.

I don't know if it's just the documentation to be updated or there is something else.