Fix/speaker backend integration#133
Conversation
WalkthroughConfiguration files for Docker Compose services are updated to define a shared network for cross-project communication. Additionally, the service stop command is refined to only stop services that are explicitly configured, rather than stopping all services unconditionally. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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. Comment |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
backends/advanced/docker-compose.yml(2 hunks)extras/speaker-recognition/docker-compose.yml(1 hunks)services.py(1 hunks)
⏰ 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). (1)
- GitHub Check: speaker-recognition-tests
🔇 Additional comments (3)
services.py (1)
308-309: LGTM! Excellent consistency improvement.Making
stop --allfilter by configured services matches thestart --allbehavior at line 291, creating a symmetric and intuitive user experience.backends/advanced/docker-compose.yml (2)
203-203: LGTM! Minor whitespace cleanup.
214-217: LGTM! Shared network completes the backend-speaker integration.This network configuration matches
extras/speaker-recognition/docker-compose.ymland enables the backend service to communicate with the speaker-recognition service using theSPEAKER_SERVICE_URLenvironment variable (line 23).
|
|
||
| # Shared network for cross-project communication | ||
| networks: | ||
| default: | ||
| name: friend-network |
There was a problem hiding this comment.
🧩 Analysis chain
LGTM! Shared network enables cross-project service communication.
The friend-network configuration allows the backend service to communicate with speaker-recognition services across Docker Compose projects. Since services.py manages both projects together, network lifecycle is handled appropriately.
Verify whether asr-services and openmemory-mcp should also use the shared network for consistency:
🏁 Script executed:
#!/bin/bash
# Check if other services have docker-compose files and whether they might need the shared network
echo "=== Checking asr-services docker-compose.yml ==="
if [ -f "extras/asr-services/docker-compose.yml" ]; then
echo "File exists. Checking for network configuration:"
grep -A 5 "^networks:" extras/asr-services/docker-compose.yml || echo "No networks block found"
else
echo "File not found"
fi
echo -e "\n=== Checking openmemory-mcp docker-compose.yml ==="
if [ -f "extras/openmemory-mcp/docker-compose.yml" ]; then
echo "File exists. Checking for network configuration:"
grep -A 5 "^networks:" extras/openmemory-mcp/docker-compose.yml || echo "No networks block found"
else
echo "File not found"
fi
echo -e "\n=== Checking if backend references these services ==="
grep -E "ASR|OPENMEMORY|asr-service|openmemory" backends/advanced/docker-compose.yml || echo "No direct references found in backend docker-compose"Length of output: 352
I need to check how OFFLINE_ASR_TCP_URI is configured and whether asr-services actually runs services that need cross-project network access.
Now I need to verify what OFFLINE_ASR_TCP_URI is configured to and whether asr-services runs services that need the shared network:The web search didn't provide clarity on the specific codebase's asr-services. Let me check the actual configuration files directly:
Based on the verification results and Docker Compose networking documentation, I have enough information to generate the rewritten review comment. The key findings are:
- Script output shows asr-services and openmemory-mcp have NO networks block (isolated networks)
- Backend references OFFLINE_ASR_TCP_URI (suggesting potential cross-project communication need)
- Docker Compose documentation confirms: by default, docker-compose projects run in separate networks; by creating an external network and declaring it in every project, containers from different projects can talk with each other
- The speaker-recognition service is now configured with friend-network, enabling backend communication
However, the key insight is that asr-services and openmemory-mcp are not explicitly configured to use the shared network, yet the backend references ASR services. This represents a potential missing configuration issue that requires the developer to verify whether these services need the shared network.
Configuration inconsistency: asr-services and openmemory-mcp should also use friend-network for cross-project communication.
The backend service references OFFLINE_ASR_TCP_URI, indicating a need for cross-project communication with services managed through services.py. Currently, only speaker-recognition uses the friend-network, but asr-services and openmemory-mcp have no explicit network configuration, leaving them in isolated project-specific networks. By default, docker-compose projects run in separate networks; however, by creating an external network and declaring it in every project, containers from different projects can talk with each other.
Add network configuration to asr-services and openmemory-mcp docker-compose files:
- Add
networksblock withname: friend-network(matching speaker-recognition) - This ensures consistent cross-project communication setup across all services managed by
services.py
🤖 Prompt for AI Agents
extras/speaker-recognition/docker-compose.yml lines 106-110: The compose file
creates an external network named friend-network for speaker-recognition, but as
noted OFFLINE_ASR_TCP_URI and backend code imply cross-project ASR
communication; inspect the asr-services and openmemory-mcp docker-compose files
and, if those services must be reachable across projects, add a networks block
pointing to the same external friend-network (matching name and external: true)
so containers live on the shared network; also verify OFFLINE_ASR_TCP_URI
resolves to the service hostname on that network and update compose/service
names or the URI accordingly.
Summary by CodeRabbit
New Features
Improvements