Divergências conhecidas

Última atualização: 20/08/2026 · Origem: docs/bugs/2026-08-13-grill-with-docs-arquitetura.md

Resumo operacional dos bugs/divergências reais já diagnosticados neste stack. Para a auditoria completa (com referências de linha), ver o documento de origem.

evo-crm fica unhealthy — db/schema.rb dessincronizado

Após up -d, o evo-crm pode subir unhealthy com ActiveRecord::PendingMigrationError, mesmo com o schema já carregado. Causa: uma entrada com versão inválida em schema_migrations (typo de ano no schema.rb do submodule) mascarava dezenas de migrations reais como “não aplicadas”. O Makefile já tem o workaround de “carimbar” migrations como aplicadas para evo-auth, mas não para evo-crm.

Contorno: rodar manualmente o mesmo carimbo de migrations para evo-crm que o make seed-crm já faz para evo-auth.

evo-auth-sidekiq sempre unhealthy (falso alarme)

A imagem do evo-auth-service-community tem um HEALTHCHECK fixo no Dockerfile (curl localhost:3001/health) que não se aplica a um worker sem porta HTTP. Ruído cosmético — nada depende desse healthcheck hoje — mas confunde monitoramento.

Contorno sugerido: healthcheck: disable: true no bloco do serviço no compose (ainda não aplicado no submodule/imagem).

Boot do Rails falha com RAILS_SERVE_STATIC_FILES=false

Um initializer do CRM (facebook_webhook_logger.rb) insere um middleware before ActionDispatch::Static incondicionalmente. Quando RAILS_SERVE_STATIC_FILES=false (padrão recomendado atrás de proxy/Traefik), esse middleware não existe na stack e o boot do Rails aborta.

Impacto: deploys de produção atrás de Traefik não sobem sem esse fix aplicado na imagem.

Gateway nginx não documentado nos docs raiz

nginx/README.md descreve um API Gateway de produção (evoapicloud/evo-crm-gateway) que roteia para os 5 serviços backend — real, mas ausente do README.md/AGENTS.md raiz.

Provisionamento de Postgres externo

Quando o Postgres é externo (gerenciado fora do stack Docker), o usuário de aplicação normalmente não tem SUPERUSER/CREATEDB — extensões e criação de schema exigem um script rodado por um usuário com privilégio elevado (ver docs/bugs/2026-08-13-provisionar-postgres-producao.sql para o script de referência, sem valores reais de host/credenciais).