Repository navigation
Conversation
There was a problem hiding this comment.
Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.
An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.
There was a problem hiding this comment.
The fix looks sound. I couldn't reproduce the CI flake here: both tests pass on the base and with this change, including when I saturated the CPU. The cause you describe does match @opentui/core's waitForFrame, which stops at the first pass when the frame loop isn't running and no render is scheduled. Starting the frame loop and waiting on the handoff complete signal removes that path. complete fires on the first frame, and the selection-copy test already uses the same pattern. The full app-lifecycle.test.tsx passes (41/0) and tsc -b is clean.
Public API: unchanged (test-only).
No concerns.
The two update-restart epilogue tests from #58139 (
restarting after an update…,quitting after a background update…) failed on bothunit (linux)runs of #58262.waitForFramestops at the first pass with no render scheduled (@opentui/coretesting.bun.js,waitForFrame). That happens on a busy runner while the home route is still loading, beforecommandsis drawn.terminalHandoff'scomplete, the same as the selection-copy test inapp-lifecycle.test.tsx.