test(plugin-qrcode): stop QR re-render poll assertions from flaking on CI#2756
Conversation
…n CI `expect.poll(() => renderUnicodeCompact).toBeCalledTimes(2)` waits for the QR re-render triggered by an interactive-prompt promise resolving. It used the default 1000ms poll timeout, which busy CI runners routinely exceed, so the Vitest job flaked with "Matcher did not succeed in time". The dev-server tests also only had the default 5s test budget (the compile wait alone can take 5s). Raise the package `testTimeout` to 20s and the two re-render polls to 10s.
🦋 Changeset detectedLatest commit: c16d7b7 The changes in this PR will be included in the next version bump. This PR includes changesets to release 0 packagesWhen changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
📝 WalkthroughWalkthroughThis PR increases test timeouts at both the Vitest configuration and individual assertion level to address flaky QR re-render polling assertions in CI. The config increases the per-test baseline to 20 seconds, and two specific test assertions explicitly set a 10-second polling timeout. ChangesQR Plugin Test Timeout Adjustments
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Merging this PR will improve performance by 14.78%
|
| Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|
| ⚡ | transform 1000 view elements |
46.2 ms | 40.2 ms | +14.78% |
Tip
Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.
Comparing fix/qrcode-poll-timeout-flake (c16d7b7) with main (bc8c3d4)2
Footnotes
-
26 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩
-
No successful run was found on
main(40701bd) during the generation of this report, so bc8c3d4 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩
UI JudgeGEQI weighted score: 60.3 / 100 across 8 examples.
DetailsResult 1
Result 2
Result 3
Result 4
Result 5
Result 6
Result 7
Result 8
|
2 participants
Summary
The
Vitest (Ubuntu)job intermittently fails onplugin-qrcode:Both sites do
await expect.poll(() => renderUnicodeCompact).toBeCalledTimes(2), waiting for the QR re-render triggered when an interactive-prompt promise resolves (resolve('bar')/resolve('main2')). They usedexpect.poll's default 1000ms timeout, which busy CI runners routinely exceed, so the poll gives up before the 2nd render lands. Locally (fast machine) it passes 9/9.The dev-server tests also ran on the default 5s test budget, even though
waitDevCompileDonealone allows up to 5s — so simply bumping the poll timeout would just hit the test timeout instead.Failing CI (before this fix)
Vitest (Ubuntu)on feat(rspeedy): lower let/const to var in output for QuickJS parse speed #2755: https://github.com/lynx-family/lynx-stack/actions/runs/26627685311/job/78469717405 — fails with "Matcher did not succeed in time" atindex.test.ts:198and:275.Fix
vitest.config.ts: raise the packagetestTimeoutto 20s (these tests legitimately spin up a real dev server).{ timeout: 10_000 }.Test-only change (no version bump). Can't be reproduced locally (passes here), so the validation is CI staying green.
Verified fixed
Vitest (Ubuntu)on this PR now passes: https://github.com/lynx-family/lynx-stack/actions/runs/26629013150/job/78474014792(The
Vitest (Windows)failure on this PR is an unrelated CI-infra issue —hashFiles(...)in the workflow template timing out on the Windows runner — not a test failure.)Test plan
Vitest (Ubuntu)passes.Vitest (Windows)— re-run to clear the unrelatedhashFilesinfra timeout.