fix(alert): wait for new deployment row in alerts e2e - #3256
Conversation
Pin all alerts-list interactions to the freshly deployed DSEQ row so the toggle and close steps stop racing notifications-chain-events when the alert hasn't propagated to /alerts within the default 15s action timeout. Removes reliance on row 0, which is non-deterministic for existing test users with prior alerts.
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
Disabled knowledge base sources:
📝 WalkthroughWalkthroughThe test refactoring updates managed-wallet-alerts to operate on the specific deployment alert row identified by ChangesUI test targeting refinement
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Suggested labels
Suggested reviewers
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3256 +/- ##
==========================================
- Coverage 66.42% 65.73% -0.69%
==========================================
Files 1036 996 -40
Lines 25425 24403 -1022
Branches 6133 5971 -162
==========================================
- Hits 16888 16041 -847
+ Misses 7459 7296 -163
+ Partials 1078 1066 -12
*This pull request uses carry forward flags. Click here to find out more. 🚀 New features to boost your workflow:
|
Why
The
Managed wallet alertsE2E (managed-wallet-alerts.spec.ts) was failing repeatedly on beta runs in the close-deployment step:The test uses
userType: "existing", so the alerts list already contains historical rows from prior runs. Previously:getAlertRow(0)was visible — true even if that row is a stale alert from a prior run.notifications-chain-eventshadn't pushed the new alert to/alertswithin the default 15s action timeout, the locator never resolved.Locally the lag is small enough to be invisible; on CI it consistently races.
What
Pin every alerts-list interaction (visibility check, toggle, link click) to a single locator filtered by the freshly created DSEQ, with a 30s wait for the new row to appear. This removes the dependency on
getAlertRow(0)(non-deterministic across runs) and givesnotifications-chain-eventsenough headroom to propagate before we drive the row.No production code changes.
Summary by CodeRabbit