-
Notifications
You must be signed in to change notification settings - Fork 6
test: fix flaky SelectionFeatureIT test #108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
WalkthroughThe changes address flaky integration tests caused by asynchronous terminal write processing in the XTerm add-on. Test infrastructure is updated to include Vaadin readiness checks, test scenarios are expanded into separate numbered methods for better isolation, and the element's sendKeys method is enhanced with an async callback to ensure terminal write completion. Copyright years are updated to 2026 across affected files. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
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 |
|



Close #107
What this PR does
This PR fixes intermittent failures in
SelectionFeatureITand other integration tests by ensuring the terminal's write queue is flushed after eachsendKeys()call.The Problem
xterm.js processes
terminal.write()calls asynchronously for performance. When our key handlers callterminal.write()with escape sequences, the buffer update happens later in the event loop. Our test assertions were sometimes running before the buffer was updated, causing flaky failures.The Fix
Modified
XTermElement.sendKeys()to useexecuteAsyncScriptwith xterm's write callback:The empty
write('')with a callback ensures all pending writes are processed before the script returns, making the test deterministic.Why not
Thread.sleep()orwaitUntil()?Thread.sleep(): Works but is non-deterministic (and slows down tests unnecessarily)waitUntil(): Doesn't help because the buffer value doesn't change between polls until the write queue is flushed. The polling reads the same stale buffer value repeatedly and there's no observable state change to wait for.Testing
SelectionFeatureITmultiple times consecutively with no failuresSummary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.