Fix Python samples failing Azure deployment due to localhost binding#187
Fix Python samples failing Azure deployment due to localhost binding#187
Conversation
Co-authored-by: joratz <43622754+joratz@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
This pull request fixes a critical deployment issue where Python agent samples fail to start on Azure App Service due to binding to localhost instead of 0.0.0.0. The fix adds production environment detection using the WEBSITE_SITE_NAME environment variable, which is automatically set by Azure App Service, to dynamically choose the appropriate host binding.
Changes:
- Added production environment detection logic to four Python sample host servers
- Modified server binding to use
0.0.0.0in production (Azure) andlocalhostfor local development - Updated startup messages to reflect the actual host being used
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| python/openai/sample-agent/host_agent_server.py | Added WEBSITE_SITE_NAME detection and dynamic host binding for production vs development |
| python/crewai/sample_agent/host_agent_server.py | Added WEBSITE_SITE_NAME detection and dynamic host binding for production vs development |
| python/claude/sample-agent/host_agent_server.py | Added WEBSITE_SITE_NAME detection and dynamic host binding for production vs development |
| python/agent-framework/sample-agent/host_agent_server.py | Added WEBSITE_SITE_NAME detection and dynamic host binding for production vs development |
| print(f"📚 Bot Framework endpoint: http://localhost:{port}/api/messages") | ||
| print(f"❤️ Health: http://localhost:{port}/api/health") |
There was a problem hiding this comment.
The endpoint URLs in the print statements still show "http://localhost:{port}" even when the server is bound to "0.0.0.0" in production. In production environments, these URLs won't accurately reflect how the service is accessed. Consider either using the actual host variable in the URLs or adding a clarifying comment that these are example local URLs for development reference only.
| print(f"📚 Bot Framework endpoint: http://localhost:{port}/api/messages") | |
| print(f"❤️ Health: http://localhost:{port}/api/health") | |
| print(f"📚 Bot Framework endpoint: http://{host}:{port}/api/messages") | |
| print(f"❤️ Health: http://{host}:{port}/api/health") |
| print(f"Bot Framework endpoint: http://localhost:{port}/api/messages") | ||
| print(f"Health: http://localhost:{port}/api/health") |
There was a problem hiding this comment.
The endpoint URLs in the print statements still show "http://localhost:{port}" even when the server is bound to "0.0.0.0" in production. In production environments, these URLs won't accurately reflect how the service is accessed. Consider either using the actual host variable in the URLs or adding a clarifying comment that these are example local URLs for development reference only.
| print(f"Bot Framework endpoint: http://localhost:{port}/api/messages") | |
| print(f"Health: http://localhost:{port}/api/health") | |
| print(f"Bot Framework endpoint: http://{host}:{port}/api/messages") | |
| print(f"Health: http://{host}:{port}/api/health") | |
| if is_production: | |
| print( | |
| "Note: In production, replace '0.0.0.0' with the externally accessible host name or IP." | |
| ) |
| print(f"📚 Bot Framework endpoint: http://localhost:{port}/api/messages") | ||
| print(f"❤️ Health: http://localhost:{port}/api/health") |
There was a problem hiding this comment.
The endpoint URLs in the print statements still show "http://localhost:{port}" even when the server is bound to "0.0.0.0" in production. In production environments, these URLs won't accurately reflect how the service is accessed. Consider either using the actual host variable in the URLs or adding a clarifying comment that these are example local URLs for development reference only.
| print(f"📚 Bot Framework endpoint: http://localhost:{port}/api/messages") | |
| print(f"❤️ Health: http://localhost:{port}/api/health") | |
| print(f"📚 Bot Framework endpoint: http://{host}:{port}/api/messages") | |
| print(f"❤️ Health: http://{host}:{port}/api/health") |
| print(f"📚 Endpoint: http://localhost:{port}/api/messages") | ||
| print(f"❤️ Health: http://localhost:{port}/api/health\n") |
There was a problem hiding this comment.
The endpoint URLs in the print statements still show "http://localhost:{port}" even when the server is bound to "0.0.0.0" in production. In production environments, these URLs won't accurately reflect how the service is accessed. Consider either using the actual host variable in the URLs or adding a clarifying comment that these are example local URLs for development reference only.
| port = desired_port + 1 | ||
|
|
||
| # Detect production environment (Azure App Service sets WEBSITE_SITE_NAME) | ||
| is_production = os.getenv("WEBSITE_SITE_NAME") is not None |
There was a problem hiding this comment.
Why do we even need this variable? We should judge if the app is in prod vs dev based on environment variable like "ENVIRONMENT" or "ASP_ENVIRONMENT" or port number, not based on website name. I think this website name itself is causing a lot of confusion and we cannot set it prod vs development in E2E. Let me know if you think otherwise
|
|
||
| # Detect production environment (Azure App Service sets WEBSITE_SITE_NAME) | ||
| is_production = os.getenv("WEBSITE_SITE_NAME") is not None | ||
| host = "0.0.0.0" if is_production else "localhost" |
There was a problem hiding this comment.
We should decide if it's prod vs local based on ip address, not the otherway around, no?
🤖 Claude Code Review SummaryReview Date: 2026-01-24T23:06:01Z Findings Summary
Findings
Overall AssessmentThe core fix is correct, security-compliant, and follows established patterns. The medium-priority log message inconsistencies are cosmetic and match the reference implementation's behavior ( The PR successfully addresses a real Azure deployment blocker with minimal risk. Review generated by Claude Code |
| print(f"🔒 Auth: {'Enabled' if auth_configuration else 'Anonymous'}") | ||
| print(f"🚀 Server: localhost:{port}") | ||
| print(f"🚀 Server: {host}:{port}") | ||
| print(f"📚 Endpoint: http://localhost:{port}/api/messages") |
There was a problem hiding this comment.
🟡 [CRM-001] Inconsistent Log Output
The print statements for Endpoint and Health URLs still display http://localhost:{port} even when the server binds to 0.0.0.0 in production. This creates misleading log output for operators monitoring Azure deployments.
Suggestion: Update to use {host} for consistency, or clarify these are local reference URLs. Note: This matches the reference implementation (Google ADK) behavior, so it's acceptable but could be improved.
| print(f"⚠️ Requested port {desired_port} busy; using fallback {port}") | ||
| print(f"\n🚀 Starting server on localhost:{port}") | ||
| print(f"\n🚀 Starting server on {host}:{port}") | ||
| print(f"📚 Bot Framework endpoint: http://localhost:{port}/api/messages") |
There was a problem hiding this comment.
🟡 [CRM-002] Inconsistent Log Output
Same issue as CRM-001 - endpoint and health URLs still reference localhost even when binding to 0.0.0.0.
Suggestion: Update for consistency with actual host binding.
| print(f"Requested port {desired_port} busy; using fallback {port}") | ||
| print(f"\nStarting server on localhost:{port}") | ||
| print(f"\nStarting server on {host}:{port}") | ||
| print(f"Bot Framework endpoint: http://localhost:{port}/api/messages") |
There was a problem hiding this comment.
🟡 [CRM-003] Inconsistent Log Output
Same issue as CRM-001 - endpoint and health URLs still reference localhost even when binding to 0.0.0.0.
Suggestion: Update for consistency with actual host binding.
| @@ -306,13 +310,13 @@ async def anonymous_claims(request, handler): | |||
| print("🎯 Compatible with Agents Playground") | |||
| if port != desired_port: | |||
There was a problem hiding this comment.
🟡 [CRM-004] Inconsistent Log Output
Same issue as CRM-001 - endpoint and health URLs still reference localhost even when binding to 0.0.0.0.
Suggestion: Update for consistency with actual host binding.
Python agent samples fail to start on Azure App Service with "site did not start within expected time" error. The servers bind to
localhostinstead of0.0.0.0, preventing Azure's load balancer from reaching the health endpoint.Changes
Added production environment detection to dynamically bind to correct host:
Files Modified
python/agent-framework/sample-agent/host_agent_server.pypython/claude/sample-agent/host_agent_server.pypython/openai/sample-agent/host_agent_server.pypython/crewai/sample_agent/host_agent_server.pyFollows existing pattern in
python/google-adk/sample-agent/main.pywhich already implements this correctly.Original prompt
This section details on the original issue you should resolve
<issue_title>"a365 deploy" failed in python/agent-framework sample because the site did not start within the expected time</issue_title>
<issue_description>Describe the bug
In the python/agent-framework sample, after successfully set up things by running:
The
a365 deployfails due to "[ERR] The deployment failed because the site did not start within the expected time."a365.deploy.log: