hholzgra I am guessing there's no way to reproduce it?

hholzgra, Thanks the report and attempts to resolve it! Like I pointed on the support page the case has too little customer data collected.
As they claim the slave(s) is (are) running per Show-Slave-Status, it would be reasonable to request
the SHOW results and ls -l master.info matching those times.

When the pair would suggest indeed no updates to the file, how about
A. if they actually use multi source replication;
B. Events coming from network are big enough and their network link is thin so 10 000 would be of some time to wait.
(The file would still be updated).

However FLUSH LOGS on the master must trigger "master.info" updating. I double-quoted the famous file name
just in case the use indeed run multi-source replication.

hholzgra, actually change master to .. master_use_gtid > no; makes the IO thread bypass updating flush_master_info (slave, when needed, resumes retrieval using gtid protocol). I hope this is what happened. Cheers.

greenman Hello. Let me redirect the issue to the docs team. I added details missing, could you please review them

in 50th change in https://mariadb.com/kb/en/library/gtid/+history
and 37th in https://mariadb.com/kb/en/library/change-master-to/+history

Thanks!

Andrei

Thanks, documentation updates look clear enough.