[codex] Wait for MCP readiness in core integration tests#24964
Conversation
|
@codex review |
|
Codex Review: Didn't find any major issues. 👍 ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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". |
|
@codex review |
![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: 52ff1333f6
ℹ️ 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".
|
|
||
| // Wait for the startup summary regardless of outcome, then interpret the | ||
| // requested server's ready, failed, or cancelled entry below. | ||
| let summary = loop { |
There was a problem hiding this comment.
I converted this from a loop with a timeout to an infinite loop, since all of our test runners enforce suite-level timeouts. No need to invite flakes on slow cloud machines from weird timing this way.
anp-oai
force-pushed
the
codex/mcp-test-readiness-waits
branch
from
52ff133 to
8de64b6
Compare
2 participants
Ensures MCP-backed
codex-coreintegration tests exercise initialized servers instead of racing server startup.I've been idly investigating a few flakes and the failure modes are much more confusing when a tool call fails because of a failed server start than when the failed server start causes the test to fail directly.