also on 10.3 http://buildbot.askmonty.org/buildbot/builders/kvm-rpm-centos73-amd64/builds/2967/steps/mtr-tcmllc/logs/stdio

10.3 ES, sles15:

main.status w3 [ fail ]
Test ended at 2020-02-19 05:17:05

CURRENT_TEST: main.status
— /home/timofey_turenko_mariadb_com/mtr-big-test/MariaDBEnterprise/mysql-test/main/status.result 2020-02-19 04:01:56.000000000 +0100
+++ /home/timofey_turenko_mariadb_com/mtr-big-test/MariaDBEnterprise/mysql-test/main/status.reject 2020-02-19 05:17:05.044114001 +0100
@@ -280,9 +280,9 @@
CALL p1();
1
1
-SELECT 9;
-9
-9
+SELECT 10;
+10
+10
disconnect con1;
connection default;
DROP PROCEDURE p1;

mysqltest: Result length mismatch

• skipping '/var/tmp/mtr/3/log/main.status/'

it is failed sporadically but really very rare... OK, I will try to repeat or understand...

The test coult global execution by query_id, probably with some condition SP/PS can be reprepare and rerun, which makes the test fail by counting one more query (or something can be done in parallel thread).

The test fails once per month on buildbot and non of 10000 run on my computer.

I think continue with the finding cause is just a wasting time.

Recent occurrence on 10.8:

main.status                              w12 [ fail ]

        Test ended at 2022-11-10 07:58:53

CURRENT_TEST: main.status

--- /home/buildbot/amd64-debian-10/build/mysql-test/main/status.result	2022-11-10 07:53:17.000000000 +0000

+++ /home/buildbot/amd64-debian-10/build/mysql-test/main/status.reject	2022-11-10 07:58:53.234855338 +0000

@@ -280,9 +280,9 @@

 CALL p1();

 1

 1

-SELECT 9;

-9

-9

+SELECT 10;

+10

+10

 disconnect con1;

 connection default;

 DROP PROCEDURE p1;

mysqltest: Result length mismatch

According to the cross-reference, this test fails in this way at least weekly in some branch, sometimes several times per day. These failures can occur also on the mandatory "branch protection" builders, as was the case above.

This failure variant is also mentioned in a comment of MDEV-8510, including some root cause analysis by kastauyra and a link to a possible fix:

I have changed the testcase to use wait_until_count_sessions.inc (Threads_connected decrement happens very late in the disconnect): https://github.com/percona/percona-server/pull/1679. The diff contains semi-related changes of reverting that previously added dump