From db05007ddb9ce85aa2a4a56cd3462e167c49e6fc Mon Sep 17 00:00:00 2001 From: DanConwayDev Date: Sat, 12 Sep 2026 16:12:21 +0000 Subject: [PATCH] test(sync): force a filter refusal under either startup ordering The adaptive regrouping test assumed one request would carry more than three filters. Minimum-churn startup can correctly split core and auxiliary coverage into two-filter requests, so the required refusal never occurred. Make the fixture accept only one filter per request. Both valid startup orderings must then exercise rejection and complete live regrouping, with the existing bounded condition and post-regrouping event assertion intact. No production request packing or peer limit handling changes. Validation: the old fixture fails in isolation without a filter refusal; the stricter fixture passes and delivers the later q-tagged issue. --- tests/sync/live_sync.rs | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tests/sync/live_sync.rs b/tests/sync/live_sync.rs index 36dd2a3..4961b6c 100644 --- a/tests/sync/live_sync.rs +++ b/tests/sync/live_sync.rs @@ -205,7 +205,9 @@ async fn test_live_sync_batches_repo_filters_below_source_req_limit() { #[tokio::test] async fn live_sync_regroups_after_filter_count_refusal() { - let source = MockRelay::start_with_max_filters(3).await; + // Minimum-churn startup can split core and auxiliary coverage into two + // filters each. A one-filter cap forces regrouping under either ordering. + let source = MockRelay::start_with_max_filters(1).await; let syncing = TestRelay::start_with_sync(None).await; let keys = Keys::generate(); let repo_id = "adaptive-filter-count";