test: reduce e2e test runtime#236
Conversation
|
Warning Review limit reached
More reviews will be available in 27 minutes and 10 seconds. Learn how PR review limits work. To continue reviewing without waiting, enable usage-based billing in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
✨ 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 |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b8a20643a6
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } | ||
|
|
||
| const delay = (ms) => new Promise((resolve) => setTimeout(resolve, ms)); | ||
| const OVERLAY_SETTLE_DELAY = 250; |
There was a problem hiding this comment.
This 250 ms constant is used by tests that immediately dereference overlayHandle and by tests that assert the overlay is absent after page.goto. The overlay is inserted by browser-side websocket/runtime-error handlers after navigation, so on slower CI a legitimate overlay can take longer than 250 ms to render; positive cases then fail with a null handle, while negative cases can pass before a late overlay appears. Please wait for the selector when an overlay is expected and use a bounded absence check for negative cases instead of shrinking the fixed sleep.
Useful? React with 👍 / 👎.
| 1000 * 2 ** 3, | ||
| ), | ||
| ); | ||
| await delay(250); |
There was a problem hiding this comment.
In the reconnect: false case there are no reconnect messages to wait on, so this 250 ms sleep is the only synchronization after server.stop(). The Disconnected! console entry is emitted from the browser's websocket close handler, which can be delivered after this short delay on slower CI, causing the snapshot to miss the expected line and flake. Please poll until consoleMessages contains the disconnect log before matching the snapshot.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e148e48485
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const waitForOverlay = (page) => | ||
| page.waitForSelector(OVERLAY_SELECTOR, { timeout: OVERLAY_TIMEOUT }); |
There was a problem hiding this comment.
This helper resolves as soon as the outer iframe is inserted, but createContainer() appends that iframe before its onload handler populates the frame body and queued error messages (client-src/overlay.ts:478-521). The positive overlay tests immediately read contentFrame().evaluate(() => document.body.outerHTML) after this wait, so on a slower Chromium run they can snapshot an empty about:blank body or fail before the overlay contents exist. Please wait for a sentinel inside the frame, such as #rspack-dev-server-client-overlay-div, instead of only the iframe element.
Useful? React with 👍 / 👎.
1 participant
Summary
This PR reduces slow e2e test runtime by shortening reconnect wait paths and reusing one Chromium process across overlay cases while keeping each test isolated in its own browser context. In local validation,
pnpm testdropped from179.62sto110.95s(~38.2% faster).Validation
pnpm testpnpm exec rstest tests/e2e/client-reconnect.test.jspnpm exec rstest tests/e2e/overlay.test.js