TRT-2678: sippy-dev MCP: sippy_serve reports server ready before HTTP API is available - #138
Open
openshift-trt-agent[bot] wants to merge 1 commit into
Open
Conversation
The sippy_serve MCP tool reported the backend as running based solely on process detection. During local dev startup, go run takes 30-60+ seconds to compile, so the process exists but the HTTP server hasn't bound yet. Downstream tools (sippy_ng_start) would start against an unready backend, causing fetch failures and app crashes. Now when an existing sippy serve process is detected, the tool polls the HTTP endpoint (up to 120s) before reporting ready. If the API never responds or the process exits during the wait, a clear error is returned. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TRT-2678: sippy_serve MCP reports server ready before HTTP API is available
Summary
sippy_serveMCP tool now polls the HTTP endpoint before reporting an existing backend process as ready, instead of relying solely on PID detection.go runcompilation), the tool waits up to 120 seconds and returns a clear error if the backend never becomes ready._pid_alive()and_wait_for_url()helpers with unit tests.Problem
During local dev startup,
go run ./cmd/sippy servetakes 30-60+ seconds to compile. The MCP tool would detect thego runprocess and report "already running" even though the HTTP server hadn't bound yet. This caused a cascading failure:sippy_servedetects the compiling process and reports readysippy_ng_startstarts the frontend on:3000/api/releasesagainst an unready backendChanges
mcp/server.py:_pid_alive(pid)helper — usesos.kill(pid, 0)to check process existence without sending a signal._wait_for_url(url, timeout, pids)— polls a URL until it responds or the timeout elapses, checking PID liveness each iteration. Same pattern as the existing_wait_for_readybut takes PIDs instead of asubprocess.Popen.sippy_serveearly-return path: when existing processes are found andrestart=False, polls the HTTP endpoint before reporting "already running". Returns a descriptive error if the API doesn't respond or the process exits.mcp/test_server.py:TestPidAlive— tests with own PID (alive) and invalid PID (dead).TestWaitForUrl— tests immediate success (mocked urlopen), process-exit detection, and timeout behavior.Test plan
_pid_aliveunit tests pass (own PID alive, nonexistent PID dead)_wait_for_urlunit tests pass (immediate success, process exit, timeout)sippy_serveand verify it waits for the HTTP API before reporting readysippy_servewhilego runis compiling — verify it polls and eventually reports readysippy_servewith a dead process PID — verify it reports the process exitedAlways review AI generated responses prior to use.
Generated with Claude Code via openshift-developer plugin
Generated with Claude Code