I’ve been testing the SonarQube MCP Server (v1.6.0.1711) with Azure AI Foundry’s MCP integration (deployed on Azure Container Apps) and encountered a critical session management issue with the HTTP transport that I wanted to bring to your attention.
The Issue
When running the server in HTTP transport mode on Azure Container Apps (Microsoft’s managed container platform), sessions are not persisting between requests. This appears to be a fundamental issue with how HTTP transport handles sessions in cloud environments. Here’s what happens:
1.Initialize request → 
Success (session created, server responds correctly)
2.Subsequent request (tools/list, tools/call, etc.) → 
Fails with “Session not found: {session-id}”
The server loses track of the session immediately after initialization, making it impossible to use any MCP tools.
Environment
Plain Text
SONARQUBE_TRANSPORT=http SONARQUBE_HTTP_HOST=0.0.0.0 SONARQUBE_HTTP_PORT=8080 Deployment: Azure Container Apps Server Version: 1.6.0.1711
The Azure Container Apps deployment is working perfectly (container healthy, Java process running, port 8080 listening, authentication via SONARQUBE_TOKEN header working ), but the session management in HTTP transport appears to be storing sessions in memory without proper persistence. This is problematic for Azure Container Apps and similar platforms where requests may be load-balanced across multiple instances or connections aren’t guaranteed to be reused.
Why This Matters
This bug makes the HTTP/HTTPS transport completely unusable for:
•Cloud deployments (Azure, AWS, GCP, etc.)
•Multi-user environments
•Any production use case requiring remote access
Currently, only stdio mode works reliably, which limits the server to local desktop use with tools like Cursor.
Reproduction
I can provide detailed reproduction steps, curl commands, and error logs if helpful. The issue is consistent and reproducible on every request after initialization.
Suggested Solutions
A few approaches that might help:
1.Implement distributed session storage (Redis, etc.)
2.Use stateless session management (embed state in tokens)
3.Add cookie-based session persistence
4.Document load balancer sticky session requirements
I noticed your recent commit “MCP-237 Do not fail when parsing unknown properties in HTTP transport” which shows you’re actively working on HTTP transport improvements. This session management issue might be worth prioritizing as it’s currently a blocker for any cloud deployment.
My Use Case
I’m using the SonarQube MCP Server with Azure AI Foundry (Microsoft’s AI development platform) which has built-in MCP integration capabilities. Azure AI Foundry connects to MCP servers via HTTP/HTTPS transport for remote access. I’ve deployed the SonarQube MCP Server to Azure Container Apps as the backend, which should be a standard deployment pattern for production MCP servers that need to be accessible by Azure AI Foundry and similar platforms.
The server would be incredibly valuable for code analysis workflows within Azure AI Foundry, but we’re currently blocked by this session management issue.
Would you be open to discussing this further? I’m happy to provide more details, testing, or even contribute to a fix if that would be helpful.
Thank you for your excellent work on this project!
Best regards,
Arun
Additional Context:
•GitHub Repo: https://github.com/SonarSource/sonarqube-mcp-server
•Latest working commit tested: c7ce125
•Error occurs in: HttpServletStreamableServerTransportProvider.doPost (line 453 )
•Platform: Azure Container Apps (Germany West Central region)
•Client: Azure AI Foundry MCP integration
•Container Image: Built from official Dockerfile
•Azure handles HTTPS termination at ingress level, container runs HTTP internally
•Use case: Remote MCP server access from Azure AI Foundry