Botond Dénes

> If it is a one off, I suggest we try to reproduce with repeat 1000 and if it doesn't reproduce, close the issue. I ran the test 1000 times...

> seen again in 5.4, reopening... > > https://jenkins.scylladb.com/job/scylla-5.4/job/scylla-ci/148/testReport/junit/boost/multishard_mutation_query_test/test_read_with_partition_row_limits/ > > maybe already fixed in master? Ppossibly yes, branch-5.4 was branched off months before the last comment stating this cannot...

Seen again in https://jenkins.scylladb.com//job/scylla-6.1/job/scylla-ci/96/testReport/junit/boost/multishard_mutation_query_test/test_read_with_partition_row_limits.

The seed from the last failure reproduces the problem locally. Finally I can debug this instead of guessing what went wrong.

> I tested the gdb commands and they seem to work but I saw that there was some special case for the read concurrency semaphore printing and 2020.1 compatibility so...

> > I tested the gdb commands and they seem to work but I saw that there was some special case for the read concurrency semaphore printing and 2020.1 compatibility...

> which breaks quorum consistency guarantees. This guarantee is out the window the moment you have sstable corruption. The quorum guarantee assumes that any majority of the nodes will have...

I think the title is misleading, it suggests that there is a bug in read-repair which causes data-resurrection, which is not true.

> > I think the title is misleading, it suggests that there is a bug in read-repair which causes data-resurrection, which is not true. > > Can you please suggest...

@raphaelsc @bhalevy is the P0 justified here? I understood that the problem is benign (but we should still fix it).