bug: fix check for server ready when using 0.0.0.0 as host#9002
Conversation
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughThe Changes
Suggested labels
Suggested reviewers
✨ Finishing Touches🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Actionable comments posted: 1
🔭 Outside diff range comments (1)
src/backend/base/langflow/__main__.py (1)
154-165: Add an explicit timeout or max-retry cap to avoid infinite waits.
wait_for_server_readywill currently loop forever if the child process never binds (e.g. mis-config, crash-on-start).
Consider accepting amax_retriesortimeoutparameter (there is already a CLI option) and raise a clear, actionable exception once exceeded.
🧹 Nitpick comments (1)
src/backend/base/langflow/__main__.py (1)
157-159: Leverageis_loopback_address()for TLS verification instead of a hard-coded tuple.Using the helper makes the intent clearer and automatically includes future loopback variants (e.g.
::1).- f"{protocol}://{health_check_host}:{port}/health", - verify=health_check_host not in ("127.0.0.1", "localhost") + f"{protocol}://{health_check_host}:{port}/health", + # Skip TLS verification for any loopback address + verify=not is_loopback_address(health_check_host)
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/backend/base/langflow/__main__.py(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
`src/backend/**/*.py`: Run make format_backend to format Python code early and often Run make lint to check for linting issues in backend Python code
src/backend/**/*.py: Run make format_backend to format Python code early and often
Run make lint to check for linting issues in backend Python code
📄 Source: CodeRabbit Inference Engine (.cursor/rules/backend_development.mdc)
List of files the instruction was applied to:
src/backend/base/langflow/__main__.py
🧠 Learnings (2)
📓 Common learnings
Learnt from: CR
PR: langflow-ai/langflow#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-06-30T14:41:58.849Z
Learning: Applies to {src/backend/tests/**/*.py,tests/**/*.py} : Test Langflow's REST API endpoints using the async 'client' fixture and assert correct status codes and response structure.
Learnt from: CR
PR: langflow-ai/langflow#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-06-30T14:41:58.849Z
Learning: Applies to src/backend/tests/**/*.py : Use the 'client' fixture (an async httpx.AsyncClient) for API tests, as defined in 'src/backend/tests/conftest.py'.
Learnt from: CR
PR: langflow-ai/langflow#0
File: .cursor/rules/backend_development.mdc:0-0
Timestamp: 2025-06-30T14:39:17.464Z
Learning: Applies to src/backend/base/langflow/components/**/*.py : Use asyncio.Queue for non-blocking queue operations in async components and handle timeouts appropriately
src/backend/base/langflow/__main__.py (1)
Learnt from: CR
PR: langflow-ai/langflow#0
File: .cursor/rules/backend_development.mdc:0-0
Timestamp: 2025-06-30T14:39:17.464Z
Learning: Applies to src/backend/base/langflow/components/**/*.py : Use asyncio.Queue for non-blocking queue operations in async components and handle timeouts appropriately
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Ruff Style Check (3.13)
- GitHub Check: Update Starter Projects
- GitHub Check: Run Ruff Check and Format
| # Use localhost for health check when host is 0.0.0.0 (bind to all interfaces) | ||
| health_check_host = "localhost" if host == "0.0.0.0" else host | ||
|
|
There was a problem hiding this comment.
Cover the IPv6 wildcard (::) as well, not just 0.0.0.0.
The server can also be started with the IPv6 “bind-all” address ::.
Without handling this case the readiness probe still fails for IPv6-only environments (e.g. Docker on Mac when IPv4 is disabled).
- # Use localhost for health check when host is 0.0.0.0 (bind to all interfaces)
- health_check_host = "localhost" if host == "0.0.0.0" else host
+ # Use localhost for health check when host is an unspecified/bind-all address
+ # – covers both IPv4 (0.0.0.0) and IPv6 (::)
+ health_check_host = "localhost" if host in ("0.0.0.0", "::") else host📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # Use localhost for health check when host is 0.0.0.0 (bind to all interfaces) | |
| health_check_host = "localhost" if host == "0.0.0.0" else host | |
| # Use localhost for health check when host is an unspecified/bind-all address | |
| # – covers both IPv4 (0.0.0.0) and IPv6 (::) | |
| health_check_host = "localhost" if host in ("0.0.0.0", "::") else host |
🤖 Prompt for AI Agents
In src/backend/base/langflow/__main__.py around lines 150 to 152, the health
check host assignment only checks for the IPv4 wildcard address "0.0.0.0" but
does not handle the IPv6 wildcard "::". Update the condition to also check if
the host is "::" and in that case set health_check_host to "localhost" to ensure
the readiness probe works correctly in IPv6-only environments.
Fixes server ready check so that wait_for_server_ready completes successfully.
Summary by CodeRabbit