fix: add timeout to API health check to prevent UI startup hang#441
Merged
Conversation
The curl health check had no --max-time, causing it to hang indefinitely when OpenCode API accepts the TCP connection but is slow to respond during initialization. This prevented the UI server from ever starting. Also switch from /health (returns SPA HTML) to /session/status (returns JSON, faster) and add -f flag to fail on HTTP errors.
Contributor
There was a problem hiding this comment.
Pull request overview
This PR prevents the Kubeflow notebook UI startup script from hanging indefinitely while waiting for the local OpenCode API to become responsive during initialization.
Changes:
- Add a hard timeout (
--max-time 2) to the API readinesscurlcheck to avoid indefinite hangs. - Switch the readiness endpoint from
/healthto/session/statusand add-fto treat HTTP errors as failures.
Comments suppressed due to low confidence (1)
docker/kubeflow/start-server.sh:55
- The loop still says "failed to start within 30 seconds", but with
curl --max-time 2plussleep 1the worst-case total wait can exceed 30s. Consider adjusting attempts/sleep/max-time or updating the error message to match the actual max wait.
if curl -sf --max-time 2 http://127.0.0.1:4096/session/status > /dev/null 2>&1; then
echo "API server is ready!"
break
fi
if [ $i -eq 30 ]; then
echo "ERROR: API server failed to start within 30 seconds"
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+49
to
+55
| for i in {1..30}; do | ||
| if curl -s http://127.0.0.1:4096/health > /dev/null 2>&1; then | ||
| if curl -sf --max-time 2 http://127.0.0.1:4096/session/status > /dev/null 2>&1; then | ||
| echo "API server is ready!" | ||
| break | ||
| fi | ||
| if [ $i -eq 30 ]; then | ||
| echo "ERROR: API server failed to start within 30 seconds" | ||
| echo "ERROR: API server failed to start within the allotted time" |
Contributor
Author
There was a problem hiding this comment.
Addressed in 3a2141f: the startup failure now reports the configured 30 attempts and 2s request timeout explicitly.
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.
Problem
After merging the Debian base image (#440), the deployed notebook shows:
Root cause: The
curl -s http://127.0.0.1:4096/healthhealth check instart-server.shhas no--max-timetimeout. When OpenCode accepts the TCP connection but is slow to respond during initialization, curl hangs indefinitely and the script never reaches theexec bun run serve-ui.tsline — so the UI never starts on port 8888.Fix
--max-time 2to curl so it times out and retries/health(returns full SPA HTML, ~2.5KB) to/session/status(returns{}, fast JSON)-fflag to fail on HTTP errorsTesting
Verified in the running pod that
curl -sf --max-time 2 http://127.0.0.1:4096/session/statusreturns immediately with exit 0.