fix(genkit-tools/mcp): Fix MCP server failing to spin up runtime #4082
Conversation
Summary of ChangesHello @ssbushi, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses a critical issue where the MCP server was failing to spin up its runtime reliably. The changes introduce a robust runtime health check, provide an optional file logging mechanism for better diagnostics, and refine the process management to ensure managed processes start correctly in a non-interactive environment with the appropriate project context. These improvements collectively aim to make the MCP server more stable and easier to debug. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request effectively resolves an issue where the MCP server could fail to properly start a runtime due to a race condition. The core of the fix is the new waitForRuntime function, which explicitly waits for the runtime process to initialize and register itself. This is a robust solution that significantly improves the reliability of the tool.
The supporting changes are also well-implemented. The modification to onRuntimeEvent to return an unsubscribe function is a crucial improvement for preventing resource leaks. The enhancements to ProcessManager for better handling of non-interactive processes and the addition of a --debug flag for file logging improve the tool's debuggability. Furthermore, the introduction of comprehensive unit tests for the new logic is commendable and ensures the changes are solid. Overall, this is a high-quality contribution that strengthens the stability and usability of the MCP server.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request addresses an issue where the MCP server fails to reliably spin up a runtime. The core of the fix is the introduction of an explicit waitForRuntime health check, which ensures the server waits for the runtime process to properly register before proceeding. The changes also include adding a file-based debug logging option, correctly setting the process to non-interactive mode, and providing the project root as the working directory. The addition of comprehensive tests for the new logic is a great touch. My review includes a couple of suggestions to enhance the robustness of the process cleanup logic and to refactor the new waitForRuntime function for better readability and maintainability.
| await new Promise<void>((resolve, reject) => { | ||
| let timeoutId: NodeJS.Timeout; | ||
| let unsubscribe: () => void; | ||
|
|
||
| const cleanup = () => { | ||
| if (timeoutId) clearTimeout(timeoutId); | ||
| if (unsubscribe) unsubscribe(); | ||
| }; | ||
|
|
||
| timeoutId = setTimeout(() => { | ||
| cleanup(); | ||
| reject(new Error('Timeout waiting for runtime to be ready')); | ||
| }, 30000); | ||
|
|
||
| unsubscribe = manager.onRuntimeEvent((event, runtime) => { | ||
| if (event === RuntimeEvent.ADD && runtime.id === runtimeId) { | ||
| cleanup(); | ||
| resolve(); | ||
| } | ||
| }); | ||
|
|
||
| processPromise | ||
| .then(() => { | ||
| cleanup(); | ||
| reject(new Error('Process exited before runtime was ready')); | ||
| }) | ||
| .catch((err) => { | ||
| cleanup(); | ||
| reject(err); | ||
| }); | ||
| }); |
There was a problem hiding this comment.
The current implementation of waitForRuntime correctly handles waiting for the runtime, timeouts, and process exits. However, the manual management of state with the cleanup function can be simplified and made more robust by using Promise.race and a try...finally block for cleanup. This approach is more declarative and less prone to race conditions in the cleanup logic, improving the code's readability and maintainability.
const TIMEOUT_MS = 30000;
let unsubscribe: () => void;
let timeoutId: NodeJS.Timeout;
try {
const runtimeAddedPromise = new Promise<void>((resolve) => {
unsubscribe = manager.onRuntimeEvent((event, runtime) => {
if (event === RuntimeEvent.ADD && runtime.id === runtimeId) {
resolve();
}
});
});
const timeoutPromise = new Promise<void>((_, reject) => {
timeoutId = setTimeout(
() => reject(new Error('Timeout waiting for runtime to be ready')),
TIMEOUT_MS
);
});
const processExitedPromise = processPromise.then(
() => Promise.reject(new Error('Process exited before runtime was ready')),
(err) => Promise.reject(err)
);
await Promise.race([
runtimeAddedPromise,
timeoutPromise,
processExitedPromise,
]);
} finally {
if (unsubscribe) unsubscribe();
if (timeoutId) clearTimeout(timeoutId);
}
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
| get runtimeId() { | ||
| return `${process.pid}${this.port !== null ? `-${this.port}` : ''}`; | ||
| return ( | ||
| process.env.GENKIT_RUNTIME_ID ?? |
There was a problem hiding this comment.
I wonder if this is correct... actually not sure if it was correct before.
the issue might come up in case of multiple genkit instances. If GENKIT_RUNTIME_ID is set, they all will have the same runtimeId, which is wrong.
I wonder if GENKIT_RUNTIME_ID can be used as prefix? So, the reflection API is allowed to append suffixes (like port number) to make ids unique, and then for your purposes you can check for prefix... WDYT?
There was a problem hiding this comment.
If this is supposed to be an ID, why should we expect that all of them will get the same ID?
I get what you're saying and I feel like if we should either:
- Rename this
GENKIT_RUNTIME_ID_PREFIXor something, if this is going to be a common env var, or - Enforce that
GENKIT_RUNTIME_IDis unique and does not already exists.
You're right, the previous logic was not correct.
2 participants
Checklist (if applicable):