See notes below explaining what this task is about and how it is to be used.

Note: items in "Report to re-check" column can be crossed as closed. It is normal and does not mean that nothing needs to be done – they are closed because they are alleged duplicates, which is the whole point.

Original report	Report to re-check	Comments
MDEV-22768	mdev22768a.test	my_message instead of my_error, 10.5 with --mysqld=--innodb (maybe not needed)
MDEV-19680	mdev19680-1.test	Unclear whether it's the same problem or not, will see when MDEV-19680 is closed
MDEV-22883	mdev22883-1.test	Unclear whether it's the same problem or not
MDEV-24644	mdev24644.test	Run with --nocheck-testcases --repeat=20 --force-restart
MDEV-21406	mdev21406.test	Causes assertion failure on 10.2
MDEV-23298	mdev23298.test
MDEV-20410	mdev20410-1.test	On 10.2-10.3
MDEV-16694	MDEV-24877
MDEV-21799	mdev21799-1.test	The MDEV has become very messy, don't want to add anything to it anymore
MDEV-27675	mdev27675.test	Another ugly test case
MDEV-24935	mdev24935.test	Different assertion, same idea
MDEV-16686	mdev16686.test	Options in the test case
MDEV-32683	mdev32683-mutex.test	Options in the test case
MDEV-31178	mdev31178-left-join.test
MDEV-26822	MDEV-32679	Options in the test case
MDEV-26509	MDEV-32693
MDEV-32684	MDEV-31551

Done

Original report	Report to re-check	Comments	Done
MDEV-16711	MDEV-16711	Check the test case without MIN/MAX
MDEV-17738	MDEV-17738	Check attached test case mdev17738-extra.test
MDEV-16903, MDEV-16905	MDEV-16903, MDEV-16905	Check one if another gets fixed; check the attached test case mdev16905x.test
MDEV-16905	MDEV-16905	Check the attached test case mdev16905x.test
MDEV-18083	MDEV-18083	Check attached test cases mdev18083-1.test.gz mdev18083-2.test mdev18083-3.test mdev18083-4.test mdev18083-5.test Run each with options listed below and with and without --nocheck-testcases --nowarnings and with big --repeat=N
MDEV-18083		When it reaches 10.4: warn3.test (with ASAN)
MDEV-18239	MDEV-18258	Non-deterministic test case in MDEV-18258 produces the failure from MDEV-18239 as well as some others
MDEV-18485	mdev18485long.test	Run with --mem --default-server-options --mysqld=--log_output=FILE --mysqld=--loose-max-statement-time=3 --mysqld=--lock-wait-timeout=2 --mysqld=--loose-innodb-lock-wait-timeout=1 --mysqld=--loose-debug_assert_on_not_freed_memory=0
MDEV-18485	MDEV-18485	There are alternative test cases in the comment(s), check them as well
MDEV-23182	MDEV-23182	mdev23182-virtual-method.test
MDEV-5628	MDEV-11779	MTR test case in comments and RQG test in the description
MDEV-16788	MDEV-16788	Check attached test cases mdev16788-1.test (debug) mdev16788-2.test (non-debug)
MDEV-16039	MDEV-17653	Different test case, slightly different stack trace on Windows non-debug
MDEV-24665	mdev24665-1.test	Must be the same problem, but since it never gets fixed in full, better check
MDEV-24665	mdev24665-2.test	Must be the same problem, but since it never gets fixed in full, better check
MDEV-24583	mdev24583-1.test	Fails with THD::is_error on 10.4
MDEV-24583	mdev24583-2.test	Details inside test files
MDEV-24583	mdev24583-3.test	Details inside test files
MDEV-24583	mdev24583-4.test	Details inside test files
MDEV-24958	mdev24958.test	On rel-ASAN build
MDEV-24786	mdev24786.test	Not necessarily the same bug, it's just a theory from a comment to MDEV-24583
MDEV-21602	MDEV-22733	Test case in the description - doesn't hang for me, but possibly something else is wrong, leaving it be
MDEV-16128	mdev16128a.test	With --default-server-options
MDEV-23160, MDEV-25564	MDEV-18157

-mem --default-server-options --mysqld=--log_output=FILE --mysqld=--max-statement-time=3 --mysqld=--lock-wait-timeout=2 --mysqld=--loose-innodb-lock-wait-timeout=1 --mysqld=--loose-debug_assert_on_not_freed_memory=0 --mysqld=--default-storage-engine=MyISAM --testcase-timeout=1

Notes:

It is going to be an on-going task until we find a better solution.

Quite often we get or create bug reports which are in all likelihood duplicates of some existing ones, but we can't be 100% sure until the original ones are fixed (even if the alleged duplicate has a test case). Keeping duplicates open is not really a solution, because original ones can stay open for months and years, and duplicates only add up the noise; and even when originals are fixed, unfortunately nobody goes through the alleged duplicates to re-verify and close them, so they stay orphans or get closed without any confirmation.

Another variation of the same problem is even when we have everything within the same bug report, the original test case can be huge and/or inconvenient for debugging, so we naturally try to simplify it. Often enough, we end up oversimplifying test cases, so when the small one gets fixed, the original one still fails. Again, unfortunately despite comments and requests to double-check before closing, it doesn't usually happen.

So, for now, I'm going to add here cases of both kinds which go through my hands. Every occurrence will be represented by a JIRA item which needs re-verification after some JIRA item gets closed. They can be either different items, or the same ones.

The task will be revised "on timer", triggered by moving due date, and notes will be added accordingly.

Everyone is welcome to add their own notes of the same kind, but please follow the pattern and do it only if the report which needs re-verification has a decently reproducible test case. This activity doesn't cover bugs which were not reproducible to begin with, and we are just guessing based on a stack trace or other effects that they might be duplicates of something.