@@ -81,7 +81,6 @@ init_per_testcase(Testcase, Config) ->
8181 rabbit_ct_helpers :testcase_started (Config1 , Testcase ).
8282
8383end_per_testcase (Testcase , Config ) ->
84- rabbit_ct_broker_helpers :rpc (Config , 0 , rabbit_db_topic_exchange , clear , []),
8584 rabbit_ct_helpers :testcase_finished (Config , Testcase ).
8685
8786% % ---------------------------------------------------------------------------
@@ -212,20 +211,24 @@ topic_trie_cleanup(Config) ->
212211 ct :pal (" Khepri version: ~b / ~s " , [KhepriVersion2 , KhepriVersion1 ]),
213212 if
214213 KhepriVersion2 >= 1704 ->
215- % % Assert that no entries were found for this vhost
216- % % after deletion.
217- ? assertEqual ([], VHostEntriesAfterDelete );
214+ % % Await until no entries remain for this vhost after
215+ % % deletion. The Khepri projection may lag on followers
216+ % % in a mixed-version cluster.
217+ ? awaitMatch (
218+ [],
219+ read_topic_trie_table (Config , Node , VHost , rabbit_khepri_topic_trie_v3 ),
220+ 30_000 );
218221 true ->
219- % % Assert that no entries were found for this vhost
220- % % after deletion. This node does not have the fixed
221- % % version of Khepri, so it won't delete the new
222- % % `#topic_trie_edge_v2{}' correctly, that's why we
223- % % filter them out.
222+ % % This branch uses a version of Khepri that has a bug,
223+ % % so it won't delete the new `#topic_trie_edge_v2{}`
224+ % % correctly. Therefore we filter those out and await only for the
225+ % % legacy entries to be gone.
224226 ct :pal (" Consider #topic_trie_edge{} records only" ),
225- ? assertEqual (
227+ ? awaitMatch (
226228 [],
227229 [E || # topic_trie_edge {} = E
228- <- VHostEntriesAfterDelete ])
230+ <- read_topic_trie_table (Config , Node , VHost , rabbit_khepri_topic_trie_v3 )],
231+ 30_000 )
229232 end
230233 end , Nodes ),
231234
0 commit comments