Israel Fruchter

> I unpacked the monitor and used ./start-all.sh --archive /path/to/where/it/was monitoring 4.7.2 was used, maybe there a mismatch, I would suggest trying with 4.7 branch

> IPv6 support might be necessary to reproduce this. > > But we don't support IPv6 in test.py, and I don't know if we do in dtest (doubt it...) we...

> Oops, apparently something in my new test is flaky (3 failures in 300 runs). I'll take a look. > Kudos for the run-all-the-tests-100-times thing. @yaronkaikov @fruch For the record,...

Just a guess Maybe a call to "storage_service/quiesce_topology" can be doing those reads ? I.e. the test is doing those calls multiple times to figure out when tablets are balanced

@ptrsmrn @nyh seem like https://github.com/scylladb/scylla-dtest/pull/5275 would do what you ask, but sounds like it might introduce flakiness to the alternator tests. I would recommend taking it for a ride with...

@Lorak-mmk can the race condition in https://github.com/scylladb/python-driver/issues/168, also happen when there are lots of schema changes one after the other ?

materialized_views_test.TestMaterializedViews.test_multi_mvs_on_different_populated_base_tables more cases of MV creating timing out https://jenkins.scylladb.com/job/scylla-master/job/gating-dtest-release/4315/testReport/junit/materialized_views_test/TestMaterializedViews/FullDtest___full_split011___test_multi_mvs_on_different_populated_base_tables/

@nyh any idea why we are seeing more and more cases of MV creation timing out ?

> @fruch - is this from the 'new batch' or existing test? it's the new batch and it taken out by https://github.com/scylladb/scylla-dtest/pull/3564

my best guess that in all those case it's during schema change, and I think we are running into https://github.com/scylladb/python-driver/issues/168