fix: stop Codex app-server EOF handler spin - #668
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 4 included reviews per hour; 3 remain after this review. 📝 WalkthroughWalkthrough
ChangesCodex output handler lifecycle
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This localized change unregisters app-server output handlers at EOF and during shutdown, with lifecycle tests added; no actionable merge-blocking risk remains beyond normal checks and review. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ 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 |
Summary
Root cause
CodexAppServerClientleft eachFileHandle.readabilityHandlerinstalled afteravailableDatareturned empty data at EOF. On macOS, an EOF descriptor remains readable, so Foundation repeatedly invoked both the stdout and stderr handlers after the app-server process exited or its pipes closed. Those two hot dispatch sources could keep roughly two CPU cores busy. The existingstop()path also terminated the process without unregistering the handlers, allowing the same spin during normal disconnects.Verification
swift test --disable-sandbox --scratch-path /Users/tanghuaizhe/Dev/open-vibe-island/.build --filter CodexAppServer— 7 tests passed.swift test --disable-sandbox --scratch-path /Users/tanghuaizhe/Dev/open-vibe-island/.build— 370 tests passed.git diff --check— passed.Summary by CodeRabbit
Bug Fixes
Tests