←
PPLX-28
Created: 2025-12-21
•
Updated: 2025-12-21
Relationships
Loading...
Attachments
Loading...
Comments (3)
agent
·
2025-12-21
## Fix Implemented
### Root Cause
docker-compose.yml line 65 had VITE_API_URL set to `http://backend:8000/api` which is a Docker-internal hostname. Browsers cannot resolve Docker container names, causing ERR_NAME_NOT_RESOLVED errors.
### Changes Made
- `docker-compose.yml:65`: Changed VITE_API_URL from `http://backend:8000/api` to `/api` (relative URL)
### How It Works
1. Browser requests pages from `localhost:8080` (nginx)
2. Frontend JavaScript makes API calls to `/api/*` (relative to current origin)
3. Nginx receives `/api/*` requests and proxies them to `http://backend:8000` (Docker-internal)
4. Backend responds, nginx forwards to browser
### Verification
Tested with chrome-devtools MCP:
- Navigated to `http://localhost:8080/library`
- Network requests show: `GET http://localhost:8080/api/threads?page=1&page_size=20`
- No ERR_NAME_NOT_RESOLVED errors
- Threads displayed correctly in UI
- Console shows no API-related errors
### Files Changed
- `docker-compose.yml` (1 file, 2 lines changed)
code-verification-qa
·
2025-12-21
[QA] FAILED - Critical bug: Frontend uses Docker-internal hostname 'backend:8000' for API calls, which cannot be resolved by browser. This causes all API requests to fail with ERR_NAME_NOT_RESOLVED.
Root cause: docker-compose.yml line 65 sets VITE_API_URL to 'http://backend:8000/api' which gets baked into the frontend build. Browser cannot resolve 'backend' hostname.
Fix required: Change VITE_API_URL in docker-compose.yml from 'http://backend:8000/api' to '/api' (relative URL) so nginx can proxy requests correctly.
Evidence:
- Browser console shows multiple ERR_NAME_NOT_RESOLVED errors
- Network requests to http://backend:8000/api/* all fail
- Direct curl tests confirm nginx proxy works: localhost:8080/api/* correctly proxies to backend
- But frontend JavaScript uses hardcoded 'http://backend:8000/api' URL
See detailed QA report: /tmp/qa-PPLX-28.md
agent
·
2025-12-21
## Implementation Complete
### Changes Made
**Files created:**
- `docker-compose.yml` - Unified deployment configuration
- `.env.example` - Environment variable template
### docker-compose.yml Features
1. **Services defined:**
- `backend` - FastAPI on port 8000
- `frontend` - React/nginx on port 8080
2. **Network:**
- Shared `perplexity-network` bridge network for inter-service communication
- Frontend nginx proxies `/api/*` requests to `http://backend:8000`
3. **Volume:**
- `perplexity-data` named volume for SQLite database persistence at `/data`
4. **Health checks:**
- Backend: Python HTTP check on `/health` endpoint
- Frontend: wget check on nginx
5. **Environment variables via .env:**
- `PERPLEXITY_API_KEY` - Required for Perplexity API
- `CORS_ORIGINS` - Optional production CORS origins
### Verification Results
All acceptance criteria verified:
- docker-compose up starts both services
- localhost:8080 loads frontend (HTML served by nginx)
- localhost:8000/health returns {"status":"healthy"}
- localhost:8080/api/health proxies to backend successfully
- API calls work (tested POST /api/threads and GET /api/threads)
- Data persists after container restart (created thread survived backend restart)
- Both containers restart cleanly via docker-compose restart