test: fix flaky SpringAnnotationCompatibilityTest.shouldSupportAnnotationAndMultipleConfig#142
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughThe PR replaces queue-based, blocking namespace polling with set-based tracking in SpringApolloEventListenerProbe and updates the test to asynchronously wait until the probe has observed the three configured namespaces in any order. ChangesEvent listener probe refactoring for async event ordering
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅ |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #142 +/- ##
============================================
+ Coverage 68.68% 71.16% +2.48%
- Complexity 1503 1639 +136
============================================
Files 212 224 +12
Lines 6396 6732 +336
Branches 647 680 +33
============================================
+ Hits 4393 4791 +398
+ Misses 1673 1592 -81
- Partials 330 349 +19 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
The test asserted that the first ApolloConfigChangeEvent received by the ApplicationListener probe is for namespace 'application'. However, config change listeners are notified asynchronously on a shared thread pool (AbstractConfig#notifyAsync), so events from different namespaces may arrive in any order, occasionally failing CI with: expected:<application[]> but was:<application[.yaml]> Replace the order-sensitive FIFO assertion with an order-independent check that all expected namespaces are eventually observed, matching the approach already used in ApolloSpringBootCompatibilityTest. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
d07caef to
f9acc43
Compare
What
Fixes a flaky test that sometimes fails CI with:
Failed runs:
Why it was flaky
The test changes config for several namespaces. Each change sends a Spring event, and all events go into one shared queue. The test then checks that the first event in the queue is for namespace
application.But Apollo sends these events on background threads (
AbstractConfig#notifyAsyncuses a thread pool), so the order they arrive is random. Most of the timeapplicationarrives first and the test passes. Sometimesapplication.yamlwins the race and the test fails.I confirmed this by logging the events: even when the
application.yamlchange was fired first, theapplicationevent could still arrive first — the order depends only on thread scheduling.Fix
Stop checking the order. Instead, wait until all expected namespaces (
application,TEST1.apollo,application.yaml) have been seen, in any order. This is the same approach already used inApolloSpringBootCompatibilityTest.Testing
🤖 Generated with Claude Code
Summary by CodeRabbit