Though on principal, master_timestamp must be greater than slave_timestamp; and if it isn't, there's a bug. Both use the value of a binlog event's when. The IO thread updates master_timestamp when a new event has come in (provided the timestamp is later than the current value), and then the transaction is written to the relay log. The SQL thread updates slave_timestamp after committing one of these transactions using that same timestamp value.

This is different than Seconds_Behind_Master, in that value is calculated using the current time (or @@timestamp) on the slave, which could allow for negative calculations.

⸺ bnestere, https://github.com/MariaDB/server/pull/3772#discussion_r1921096290

However, this assertion I tried to add

--- a/sql/slave.cc

+++ b/sql/slave.cc

@@ -3146,6 +3147,8 @@ void store_master_info(THD *thd, Master_info *mi, TABLE *table,

     if ((slave_timestamp= mi->rli.slave_timestamp))

     {

       (*field++)->store_timestamp((my_time_t) slave_timestamp, 0);

+      // primary's binlog timestamp should be >= replica's replication timestamp

+      DBUG_ASSERT(master_timestamp >= slave_timestamp);

       (*field++)->store((uint) (master_timestamp - slave_timestamp), true);

     }

     else

fails in rpl_gtid_crash both locally and on Debian Buildbots.

Either this is a potential bug, or we (including this cast immediately after the added line) were unaware that this difference could be negative.