fix(compose): set EVO_AUTH_BASE_URL on evo-processor (EVO-1683)#126
Conversation
Processor caía no default localhost:3001 e retornava 503 ao validar token, pois o bloco environment não definia EVO_AUTH_BASE_URL e o serviço de auth não estava em depends_on. Alinha com evo-core (EVO_AUTH_SERVICE_URL). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Reviewer's guide (collapsed on small PRs)Reviewer's GuideUpdates evo-processor service in docker-compose to explicitly point at evo-auth via EVO_AUTH_BASE_URL and to wait for evo-auth’s healthcheck before starting, preventing it from defaulting to localhost and failing bearer token validation. File-Level Changes
Possibly linked issues
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey - I've found 1 issue
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="docker-compose.yml" line_range="240-237" />
<code_context>
condition: service_healthy
redis:
condition: service_healthy
+ evo-auth:
+ condition: service_healthy
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
</code_context>
<issue_to_address>
**issue:** Double-check that the `evo-auth` service defines a compatible `healthcheck` since processor now depends on it.
Ensure `evo-auth`’s healthcheck only reports healthy once the auth API is actually ready to handle requests; otherwise the new `service_healthy` dependency may still allow flaky startup ordering.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| - processor_logs:/app/logs | ||
| depends_on: | ||
| postgres: | ||
| condition: service_healthy |
There was a problem hiding this comment.
issue: Double-check that the evo-auth service defines a compatible healthcheck since processor now depends on it.
Ensure evo-auth’s healthcheck only reports healthy once the auth API is actually ready to handle requests; otherwise the new service_healthy dependency may still allow flaky startup ordering.
dpaes
left a comment
There was a problem hiding this comment.
Approved — merging to develop.
XS docker-compose fix. Verified against the compose file (not just the diff):
- Host
evo-auth:3001matches the actual auth service name (hyphen) and port — byte-identical toevo-core's existingEVO_AUTH_BASE_URL(line 199), which is known-good. depends_on: evo-auth { condition: service_healthy }is valid becauseevo-authdefines a healthcheck (lines 67–72); same dependency pattern already used byevo-crm/evo-frontend.- No
.envcollision: Composeenvironment:precedence overridesenv_file, and the value is a literal (no${...}interpolation).
Documented scope deferrals (no depends_on: evo-auth on evo-core, optional settings.py:51 default left as-is) are reasonable — the in-container override already unblocks token validation.
Summary
EVO_AUTH_BASE_URL: http://evo-auth:3001noenvironmentdo serviçoevo-processorevo-authaodepends_ondoevo-processor(condition: service_healthy) para garantir ordem de subidaWhy
Processor caía no default
localhost:3001(desrc/config/settings.py:51) e retornava503 ERR_SERVICE_UNAVAILABLEao validar bearer token, com logEvoAuth: Network error for POST /api/v1/auth/validate: All connection attempts failed. Cliente precisava aplicar workaround manual no compose.Agora alinha com
evo-core, que já consome o mesmo host viaEVO_AUTH_BASE_URL(corrigindo nome de var citado erroneamente comoEVO_AUTH_SERVICE_URLno commit body — quem usa essa variante éevo-crm/evo-crm-sidekiq).Validation
docker compose configparseia OKevo-processoremdocker compose config:EVO_AUTH_BASE_URL: http://evo-auth:3001✅depends_on: [evo-auth, postgres, redis]✅docker compose exec evo-processor env | grep EVO_AUTH_BASE_URL→http://evo-auth:3001python -c "urllib.request.urlopen('http://evo-auth:3001/up')"→ HTTP 200Token validation successful for user: admin@evo.local(zeroAll connection attempts failed)Out of scope (deliberadamente)
evo-coretambém não temdepends_on: evo-auth. Tecnicamente o mesmo padrão, mas sem evidência de incidente reportado e Rails tem retry no boot que mascara a janela. Vira card próprio se aparecer relato.settings.pydefault (issue §4, marcado como opcional). Fix primário no compose já destrava o cliente.Changed Files
docker-compose.ymlLinked Issue