mirror of
https://github.com/scylladb/scylladb.git
synced 2026-06-06 15:03:06 +00:00
fb37394995
If a set of mutations contains both an entry that deletes a table and an entry that adds a table with the same name, it's expected to be a replacement operation (delete old + create new), rather than a useless "try to create a table even though it exists already and then immediately delete the original one" operation. As such, notifications about the deletions should be performed before notifications about the creations. The place that originally suffered from this wrong order is view building - which in this case created an incorrect duplicated entry in the view building bookkeeping, and then immediately deleted it, resulting in having old, deprecated entries with stale UUIDS lying in the build queue and never proceeding, because the underlying table is long gone. The issue is fixed by ensuring the order of notifications: - drops are announced first, view drops are announced before table drops; - creations follow, table creations are announced before views; - finally, changes to tables and views are announced; Fixes #4382 Tests: unit(dev), mv_populating_from_existing_data_during_node_stop_test