Botond Dénes

> > The empty pages are sent every time, if they are sent. > > I don't understand. What does this imply? > > Does Scylla keep sending empty pages...

> > So given a long string of tombstones, the client can get arbitrary amount of empty pages during the query. > > And how does that interact with `LIMIT...

We have another mysterious issue where data is simply missing: https://github.com/scylladb/scylladb/issues/24572

Another synchronous MV update test failure seen in https://jenkins.scylladb.com/job/scylla-master/job/scylla-ci/4013/ For searchability: Tests / Unit Tests / test_materialized_view.test_mv_synchronous_updates

> Is it different than [#22040](https://github.com/scylladb/scylladb/issues/22040) ? Yes, at least the place of the crash is. Maybe the underlying issue is the same, not sure.

Uploading logs: [test_tablet_cannot_decommision_below_replication_factor.debug.1.zip](https://github.com/user-attachments/files/19972038/test_tablet_cannot_decommision_below_replication_factor.debug.1.zip) @xemul please always upload logs, the jenkins jobs are cleaned up after a few weeks.

Just before the crash, I see this in the logs: ``` INFO 2025-04-15 22:49:06,594 [shard 0: gms] table - Detected tablet merge for table test_1744746538398_cghup.test, decreasing from 8 to 4...

Looks like reads against some `storage_group`, don't take its `async_gate()`, so they won't prevent the storage-group from being closed while they are ongoing.

After some further thinking and digging, I think we only need special handling for memtable readers: * cache is table-wide, so cache readers don't need to worry about cache going...

I reproduced this with a simple migration too.