fix(client): wait for toast to clear before re-checking identical Mongo replica-set error#41963
fix(client): wait for toast to clear before re-checking identical Mongo replica-set error#41963wyattwalter wants to merge 1 commit into
Conversation
…go replica-set error ConnectionErrors_Spec.ts asserted the same "REPLICA_SET connections should not be given a port" toast twice in a row without waiting for the first one to disappear. Toastify doesn't reliably mount a second DOM node for an identical message while the prior one is still visible/fading, causing an intermittent 60s timeout on the second assertion. Add the same WaitUntilAllToastsDisappear() call already used elsewhere in this spec before repeated identical-message checks.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughA single-line change adds a wait for all toast notifications to disappear after a specific error assertion in the MongoDB connection errors Cypress test, before proceeding with subsequent test steps. ChangesTest synchronization fix
Estimated code review effort: 1 (Trivial) | ~2 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 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 |
Description
ConnectionErrors_Spec.ts's "3. Mongo connection errors" test asserts the exact same toast message twice in a row (REPLICA_SET connections should not be given a port...) — once right after switching Connection type to "Replica set", and again right after filling in host/port. Every other repeated-message check in this same spec callsWaitUntilAllToastsDisappear()in between; this one didn't.Toastify doesn't reliably mount a new DOM node for an identical message while the previous instance is still visible/fading, so the second
ValidateToastMessagecall can time out waiting fordiv.Toastify__toast— intermittently, depending on exact timing. This caused a real CI failure on an unrelated release-promotion PR (EE #9268 / CE #41961), reproduced consistently across 3 retries in that run.Fix: add the same
WaitUntilAllToastsDisappear()call used elsewhere in this spec before the second identical-message check.Root cause detail
From the failing run's logs: the backend correctly returned the
TEST_DATASOURCE_ERRORaction with the replica-set-port error message both times (confirmed via the intercepted@testDatasourceXHR), so this is a test-timing issue, not a backend regression.Test plan
ConnectionErrors_Spec.tspasses reliably in CI (no test-plugin infra changes required, so no server-side test coverage needed)Summary by CodeRabbit