test(unit): fix flaky mongo connection test - #41526
Conversation
|
Looks like this PR is ready to merge! 🎉 |
|
WalkthroughReconnect-related connection tests now wait for a ChangesConnection Test Reliability
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
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 |
There was a problem hiding this comment.
All reported issues were addressed across 1 file
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #41526 +/- ##
========================================
Coverage 68.68% 68.68%
========================================
Files 4135 4135
Lines 160461 160461
Branches 29186 29251 +65
========================================
+ Hits 110215 110217 +2
+ Misses 45137 45135 -2
Partials 5109 5109
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
|
/jira ARCH-2200 |
Proposed changes (including videos or screenshots)
Problem
Connection.spec.tshad a flaky reconnect test (should reset retryCount on a successful connection…) that intermittently failed in CI withExpected: "connected" / Received: "connecting".The reconnect helper blocks waited on
connection.once('connection', …), but the'connection'event fires on every status transition. During a reconnect the sequence isreconnecting → connecting → connected, soonceresolved on the very first emission ('reconnecting') — two transitions early. That lethandleConnectionresolve before the handshake finished, so the synchronousexpect(connection.status).toBe('connected')on the next line raced the message delivery. It passed on fast/idle machines and lost under CI load.Fix
Replaced the
once('connection', …)waiters with a value-gatedon('connection', …)listener that only resolves once status actually reaches'connected', then detaches itself. Applied to all four reconnect blocks in the spec. This keeps the same observation channel and leaves every assertion unchanged — it only stops resolving on the intermediate'reconnecting'state.No production code changed; this is purely a test-synchronization fix.
Issue(s)
Steps to test or reproduce
Further comments
Summary by CodeRabbit
Task: ARCH-2292