Incidentes e Bugs Resolvidos

ComercialRS — firecrawl-extract-meeting "Multicálculo saúde..." (Jun 2026) ✅ CORRIGIDO

Problema: Ao colar URL do Painel (app2.paineldocorretor.com.br/crm/negocios/), o servidor retornava "Multicálculo saúde feito para corretores..." em vez do nome real do cliente. Também retornava channel no JSON.

Causa Raiz:

1. O servidor Python firecrawl_server.py buscava a URL sem autenticação → recebia landing page genérica → extraía OG tag "Multicálculo..."

2. Conexão com banco Postgres usava localhost:5432 (Supabase Cloud) em vez de localhost:5433 (CommercialRS local) → lookup no banco sempre retornava nada

3. Campo channel estava sendo retornado na API

Correção:

1. Conexão Python → localhost:5433 (deploy-vps-db-1 CommercialRS)

2. URLs do Painel: lookup no banco primeiro (tasks.title), se não encontrar usa "Reunião" genérico (sem web fetch)

3. Campo channel removido do retorno da API

Arquivo: /var/www/comercialrs/firecrawl_server.py

Skill: comercialrs-painel-url-lookup

Hermes Insights — Build/Deploy Quebrado (Jun 2026) ✅ CORRIGIDO

Problema: Build React não gerava bundle JS. index.html apontava para arquivo errado.

Causa:

- Existiam 2 index.html: /root/hermes-insights/index.html (11KB, HTML estático legado) e src/main.tsx (entry real do React)
- Build usava src/main.tsx mas index.html antigo tinha script tag diferente
- Resultado: build mostrava "2 modules" em vez de "3,139 modules"

Solução:

1. Renomeou index.html → index_static.html (preservou relatórios legados)

2. Criou novo index.html com script tag correta para src/main.tsx

3. Build passou a gerar 948KB de JS

4. Deploy: cp -r dist/* /var/www/hermes-insights/

Arquivos críticos:

- /root/hermes-insights/index.html — NOVA entrada React
- /root/hermes-insights/index_static.html — RENAMED (era o antigo)

Hermes Insights — Sync Script Paralisado (Jun 2026) ✅ CORRIGIDO

Problema: Script /usr/local/bin/hermes-sync.py não insertava dados no Supabase.

Causas múltiplas:

1. sb_exec() retornava [] em sucesso (INSERT PostgreSQL retorna []). if sb(sql) era falsy mesmo em sucesso → inserts pulados

2. chatwoot_inbox_id NOT NULL — coluna não estava nos INSERTs

3. sync_status = 'outdated' — valor não existe no enum (válidos: pending, synced, partial, failed)

4. sender_id NULL tratado como string 'NULL' em vez de SQL NULL

5. Limite de 14 dias + 400 conversas (muito restritivo)

Soluções:

1. Split sb() em sb_exec() (INSERT/UPDATE → True/None) e sb() (SELECT → list/[])

2. Adicionou chatwoot_inbox_id em todos os INSERTs

3. Mudou 'outdated' → 'partial'

4. sender_id NULL tratado com tracking variable

5. 14 dias → 90 dias, 400 → 2000 por execução

Hermes Insights — RPC Retornava 400 Bad Request (Jun 2026) ✅ CORRIGIDO

Problema: get_conversations_audit RPC retornava 400.

Causa: Tipos colunas não batiam. chatwoot_id era INTEGER mas Chatwoot mandava números grandes.

Solução: Cast explícito: chatwoot_id::bigint

Também corrigido:

- get_agents_ranking RPC apagada acidentalmente → recriada

ComercialRS — firecrawl-extract-meeting retornando "Multicálculo saúde" em vez do nome real (Jun 2026) ✅ CORRIGIDO

Problema: Ao colar link do Painel (app2.paineldocorretor.com.br/crm/negocios/), o CommercialRS mostrava "Multicálculo saúde feito para corretores..." como nome, e channel aparecia no frontend quando não era mais necessário.

Causa:

1. O servidor Python firecrawl_server.py (porta 9085) fazia fetch direto da URL sem autenticação → recebia página de landing genérica → extraía OG tags dela

2. Campo channel ainda presente no retorno mesmo não sendo mais usado pelo frontend

Solução:

1. Removido campo channel do retorno da API em todos os casos

2. Adicionada busca no banco local (tabela tasks) quando URL é do Painel:

- Extrai UUID da URL (/crm/negocios/)

- Consulta SELECT title FROM tasks WHERE link LIKE '%%'

- Usa title da DB se encontrar → nome real do lead

- Fallback: continua com lógica de scrape (para URLs não-Painel)

3. Postgres acessível em 127.0.0.1:5433 (porta 5432 mapeada do container deploy-vps-db-1)

Arquivos críticos:

- /var/www/comercialrs/firecrawl_server.py — servidor Python (porta 9085)
- deploy-vps-db-1 — Postgres container com tabela tasks
- Variáveis de ambiente: PGPORT=5433 PGHOST=127.0.0.1 PGUSER=postgres PGPASSWORD='' PGDATABASE=postgres

Teste:

`bash

UUID que existe na DB → nome real

curl -s -X POST http://localhost:9085/functions/v1/firecrawl-extract-meeting \

-H "Content-Type: application/json" \

-d '{"url":"https://app2.paineldocorretor.com.br/crm/negocios/a1165433-9bc9-4dfb-bdb8-d3309fbc2973"}'

Retorna: {"name":"Angela Kelle Rodrigues de Jesus", ...} ✅

UUID inexistente → fallback "Reunião"

curl -s -X POST http://localhost:9085/functions/v1/firecrawl-extract-meeting \

-H "Content-Type: application/json" \

-d '{"url":"https://app2.paineldocorretor.com.br/crm/negocios/f733c613-a104-4885-b837-0402badefb64"}'

Retorna: {"name":"Reunião", ...} ✅

- get_dashboard_stats bloqueada por RLS cross-schema → derivada do ranking no frontend
- GRANT USAGE no schema insights para anon (RLS bloqueava)

WhatsApp Bloqueado — UAZAPI (Mai 2026) 🔴 CRÍTICO

Problema: Número WhatsApp bloqueado por 5 horas.

Causa: Webhook configurado no banco de dados quando já estava configurado no site UAZAPI. Duplicação de envios = spam = bloqueio.

Regra estabelecida:

> NUNCA tocar webhook no banco — conexão já está no site UAZAPI/Meta. Tocar = bloqueio.

Solução: Reconectado token no site do ComercialRS.

Alertas Duplicados (Mai 2026)

Problema: Corretores recebiam mensagens duplicadas de alerta.

Causa: Sistema verificava a cada 30min sem throttle.

Solução: Implementado throttle de 30min em alert_throttle table.

Tela Preta — Filtro de Datas (Mai 2026)

Problema: Clicar para definir período de data causava tela preta.

Causa: t.dueDate.split('T')[0] sem null-check em Dashboard.tsx.

Solução: Added guard: t.dueDate ? t.dueDate.split('T')[0] : ''

Accesso Maju (Mai 2026) ⚠️ PENDENTE

Problema: maria.giulha@rochasalesseguros.com.br não conseguia acessar.

Causa: Conta criada mas email nunca confirmado (email_confirmed_at = NULL).

Status: Resolução pendente — necesita senha reset via admin-reset-user-password.

Botão "Iniciada" Não Parava Alertas (Mai 2026)

Problema: Clicar "Iniciada" atualizava task mas vendedor continuava recebendo alertas.

Causa: Task já estava "agendada" no ciclo do cron antes do clique.

Solução necessária: task_alerts.py precisa excluir tasks com status IN ('in_progress', 'completed').

Meta Webhook — Timestamp Vazio (Mai 2026)

Problema: Erro invalid input syntax for type bigint: "" no log.

Causa: timestamp vazio sendo passado no insert de incoming_messages.

Impacto: Nenhum — task era atualizada corretamente.

DocCorretor — Pastas Vazias (Jun 2026)

Problema: App mostrava lista vazia de clientes.

Causa: Migração Drive criou registros em documents mas não em clients.

Solução: Migração completa refeita — 138 docs, 138 arquivos, 12 clientes.

PostgREST Null Filter — Bug Silencioso (Jun 2026)

Problema: Filtro is=column.null retornava 400 sem mensagem.

Solução: Sintaxe correta: column=is.null

ComercialRS — Edge Functions Self-Hosted Retornando Apenas channel (Jun 2026) → ✅ RESOLVIDO

Problema: Após migração do banco para self-hosted, extração de reunião retornava SOMENTE channel (video/mensagem), sem name, date, time, notes.

Causa Raiz — Investigação Completa:

1. Supabase Cloud Egress Bloqueado: https://dauftiqcvgaydddoxqhh.supabase.co retorna exceed_egress_quota — Edge Functions Cloud não funcionam mais. ✅Confirmado

2. Edge Functions Self-Hosted 401/403: Edge Runtime do Supabase tem autenticação built-in que não pode ser desabilitada via VERIFY_JWT=false. O Edge Runtime valida JWT internamente antes de executar qualquer função:

- role=anon → 401 Unauthorized (sem sub)

- role=service_role com sub=0000...000 → passa verificação mas falha ao buscar perfil em auth.profiles (não existe) → 403 Forbidden

✅Confirmado — o Edge Runtime valida ANTES de executar a função

3. Servidor Python Existente na Porta 9085: Já existia um servidor Python na porta 9085 que responde em /functions/v1/firecrawl-extract-meeting com dados completos! ✅Confirmado

Solução Aplicada (2026-06-24):

1. Adicionada rota firecrawl no Kong (/docker/deploy-vps/kong.yml) apontando para http://172.17.0.1:9085 (servidor Python no host)

2. Removido key-auth,acl do KONG_PLUGINS — estava sendo ignorado mas agora Kong foi recriado com request-transformer,cors apenas ✅

3. Rota Kong: strip_path: false para preservar o path completo ao proxy_pass

Configuração Kong (/docker/deploy-vps/kong.yml):

`yaml

- name: firecrawl

url: http://172.17.0.1:9085

routes:

- paths:

- /functions/v1/firecrawl-extract-meeting

strip_path: false

Resultado — Teste OK:

`json

{

"success": true,

"data": {

"name": "Join our Cloud HD Video Meeting",

"date": null,

"time": null,

"channel": "video",

"notes": "Zoom is the leader in modern enterprise communications...",

"url": "https://zoom.us/j/123456789",

"meetingId": "123456789"

}

Melhorias Aplicadas (2026-06-24 tarde):

1. Canal para WhatsApp/Telefone: detect_channel() agora verifica URL ANTES do HTML, evitando problemas com redirects que mudam o HTML para página genérica do WhatsApp.

2. Nome para links genéricos: Se og:title ou </code> retornam valores genéricos como "Share on WhatsApp", "WhatsApp", "Meet", o servidor deriva o nome da URL (<code>wa.me</code> → "WhatsApp", <code>tel:</code> → "Ligação Telefónica").3. Suporte a URLs <code>tel:</code>: Links <code>tel:+55...</code> são tratados diretamente sem fetch HTTP, retornando <code>channel: telefone</code> e <code>name: Ligação para <número></code>.4. Data sempre hoje: <code>extract_date_time()</code> agora retorna <code>date = date.today()</code> (data do servidor).5. Hora extraída do URL: Padrões <code>XXhXX</code> e <code>XXh</code> são buscados tanto no HTML quanto no URL (ex: <code>?pwd=reuniao15h30</code> → <code>time: "15:30"</code>).Testes Realizados: <li>- <code>wa.me/5511999999999</code> → <code>name: "WhatsApp"</code>, <code>channel: "mensagem"</code> ✅</li> <li>- <code>tel:+556130083803</code> → <code>name: "Ligação para +556**3803"</code>, <code>channel: "telefone"</code> ✅</li> <li>- <code>zoom.us/j/123456789?pwd=reuniao15h30</code> → <code>time: "15:30"</code>, <code>date: "2026-06-24"</code> ✅</li> <li>- Zoom/Meet genérico → <code>channel: "video"</code> ✅</li>Nota: O servidor Python na porta 9085 é o responsável pela extração real. O Edge Runtime do Supabase não está sendo usado para essa função.Status: ✅ RESOLVIDO — Kong agora roteia <code>/functions/v1/firecrawl-extract-meeting</code> para o servidor Python existente<hr><h2>ComercialRS — addTask AppDataContext Com Mensagens de Reunião (Jul 2026) ✅ CORRIGIDO</h2> Problema: Ao criar actividade em <code>/atividades</code> → botão "Nova Actividade" → preenchia e confirmava → o toast mostrava "Reunião criada com sucesso!" em vez de "Actividade criada com sucesso!".Causa Raiz: O <code>addTask</code> no <code>AppDataContext</code> (<code>src/context/AppDataContext.tsx</code>) tinha lógica de reunião misturada — especificamente:1. Bloco de verificação duplicada por link CRM (só faz sentido para reuniões): <code>`</code>tsx if (taskLink) { const { data: existingByLink } = await supabase.from('tasks').select(...) if (existingByLink && existingByLink.length > 0) { toast.error('Já existe uma reunião ativa para este lead.'); // ← errado para actividades return false; } } <code>`</code> 2. Mensagens de erro com "reunião": - <code>toast.error('Esta reunião já foi criada.')</code> - <code>toast.error('Erro ao criar reunião: ' + ...)</code> - <code>toast('Reunião criada com sucesso!')</code> ← mas este estava no MeetingCreateDialog, não aquiSolução Aplicada: <li>- Removido o bloco de verificação <code>existingByLink</code> do <code>addTask</code> — essa lógica não pertence a actividades (que podem ter qualquer channel e não precisam de link CRM)</li> <li>- Corrigidas mensagens de erro:</li> - <code>'Esta reunião já foi criada.'</code> → <code>'Esta actividade já foi criada.'</code> - <code>'Erro ao criar reunião: '</code> → <code>'Erro ao criar actividade: '</code>Ficheiro: <code>/tmp/comercialrs_build/src/context/AppDataContext.tsx</code>Nota: O <code>MeetingCreateDialog</code> (página <code>/tasks</code>) JÁ usa consistentemente "Reunião" — não precisa de alterações.Status: ✅ CORRIGIDO — Build <code>main-BNqWkMa7.js</code> deployed<hr><h2>ComercialRS — Kong: Rota firecrawl Missing no Ficheiro Activo (Jul 2026) ✅ CORRIGIDO</h2> Problema: Ao criar reunião em <code>/tasks</code>, erro antigo do Edge Function aparecia — a rota <code>/functions/v1/firecrawl-extract-meeting</code> não respondia via Kong.Causa Raiz:1. Rota firecrawl ausente no Kong activo: O ficheiro <code>/opt/rochasales/volumes/api/kong.yml</code> (usado pelo Kong em produção) não tinha a rota <code>firecrawl</code>. Apenas <code>/docker/deploy-vps/kong.yml</code> tinha — e esse nunca foi deployments activo.2. firecrawl_server.py ausente no VPS: O ficheiro <code>/var/www/comercialrs/firecrawl_server.py</code> não existia no VPS — apenas nas pastas de build locais (<code>/tmp/comercialrs_build/</code>). O serviço <code>firecrawl</code> estava inactive (dead).Solução Aplicada (2026-07-13):1. Copiado <code>firecrawl_server.py</code> do build local para o VPS: <code>`</code>bash scp /tmp/comercialrs_build/firecrawl_server.py root@31.97.243.106:/var/www/comercialrs/firecrawl_server.py <code>`</code>2. Iniciado o serviço: <code>`</code>bash systemctl start firecrawl systemctl status firecrawl # → active (running) <code>`</code>3. Adicionada rota no <code>/opt/rochasales/volumes/api/kong.yml</code> (ficheiro activo do Kong): <code>`</code>yaml - name: firecrawl url: http://172.23.0.1:9085 routes: - name: firecrawl-route paths: - /functions/v1/firecrawl-extract-meeting strip_path: false <code>`</code> Nota: <code>172.23.0.1</code> = gateway da rede <code>deploy-vps_default</code> onde o KongContainer está. <code>9085</code> = porta onde o servidor Python escuta no host. <code>host.docker.internal</code> não funciona neste ambiente.4. Reiniciado Kong: <code>`</code>bash docker restart rochasales-kong-1 && sleep 8 <code>`</code>5. Teste confirmado: <code>`</code>bash curl -s -X POST https://comercialrs.rochasalesseguros.com.br/functions/v1/firecrawl-extract-meeting \ -H 'Content-Type: application/json' \ -d '{"url":"https://wa.me/5511999999999"}' # → {"success": true, "data": {"name": "Share on WhatsApp", "channel": "call", ...}} <code>`</code>Ficheiros Modificados: <li>- <code>/var/www/comercialrs/firecrawl_server.py</code> — copiado do build local</li> <li>- <code>/opt/rochasales/volumes/api/kong.yml</code> — rota firecrawl adicionada</li>IP Gateway discovery: <code>`</code>bash docker inspect rochasales-kong-1 | jq '.[].NetworkSettings.Networks' <h1>deploy-vps_default: 172.23.0.4, rochasales_default: 172.28.0.2</h1> <h1>Kong container rede deploy-vps_default → gateway = 172.23.0.1 (host)</h1> <code>`</code>Status: ✅ RESOLVIDO<hr><h2>ComercialRS — TaskCreateDialog: Erros de Português (Jul 2026) ✅ CORRIGIDO</h2> Problema: Diálogo "Nova Actividade" em <code>/atividades</code> mostrava "Proyecto", "Sem proyecto" (espanhol) em vez de "Projeto", "Sem projeto" (português).Erros corrigidos em <code>src/components/tasks/TaskCreateDialog.tsx</code>: <li>- <code>Proyecto</code> → <code>Projeto</code></li> <li>- <code>Sem proyecto</code> → <code>Sem projeto</code></li> <li>- <code>Criando...</code> → <code>A criar...</code></li>Ficheiro: <code>/tmp/comercialrs_build/src/components/tasks/TaskCreateDialog.tsx</code>Status: ✅ CORRIGIDO — Build <code>main-BIHbZeX_.js</code> deployed<hr><h2>ComercialRS — manualChunks Vite Quebrando @hello-pangea/dnd (Jul 2026) ✅ CORRIGIDO</h2> Problema: <code>useSyncExternalStore</code> error quando se abria a página <code>/atividades</code> — browser mostrava erro ecrã branco.Causa Raiz: O <code>manualChunks</code> no <code>vite.config.ts</code> isolava <code>@hello-pangea/dnd</code> (biblioteca drag-and-drop) num chunk separado. Esta biblioteca internamente usa <code>useSyncExternalStore</code> do React — mas como estava num chunk isolado, o contexto React não estava disponível, causando <code>TypeError: Cannot read properties of undefined (reading 'useSyncExternalStore')</code>.Solução: Removido TODO o <code>manualChunks</code> do <code>vite.config.ts</code>. Agora o Vite faz bundling natural — tudo num único <code>main-8iByHy4e.js</code> (765KB).Build output após fix: <code>`</code> dist/assets/main-8iByHy4e.js 783.40 kB │ gzip: 234.37 kB <code>`</code>Nota: O warning "Some chunks are larger than 500 kB" é aceite — é preferível ter um bundle grande mas funcional do que dois chunks pequenos mas quebrados.Status: ✅ RESOLVIDO<hr><h2>ComercialRS — Actividades vs Reunioes: Separação Completa (Jul 2026) ✅ CORRIGIDO</h2> Problema: Actividades (kanban de actividades de projecto) e Reuniões (tarefas standalone/lead) estavam a partilhar o mesmo formulário e kanban, causando confusão.Solução Implementada:1. Duas páginas separadas: - <code>/atividades</code> → <code>Activities.tsx</code> → usa <code>ProjectKanbanBoard</code> (5 colunas: Ideia, A fazer, Em execução, Em validação, Concluído) - <code>/tasks</code> → <code>Tasks.tsx</code> → usa <code>KanbanBoard</code> (4 colunas: A fazer, Iniciada, Concluído, Remarketing)2. Filtro de actividades por project_id: <code>`</code>tsx // Activities.tsx — só mostra tarefas com project_id real filteredTasks = allActiveTasks.filter(t => { if (!t.projectId) return false; // exclui tarefas sem proyecto return true; }); <code>`</code> Resultado: 4 actividades (com proyecto) vs 1097 tarefas (todas)3. Dois diálogos de criação: - <code>TaskCreateDialog.tsx</code> (Actividades) — Nome/Empresa, Projeto (dropdown), Descrição, Progresso, Prioridade, Responsável, Data início/fim - <code>MeetingCreateDialog.tsx</code> (Reuniões) — Link CRM (auto-fill), Nome/Empresa, Canal (Vídeo/Mensagem/Telefone), Prioridade, Responsável, Data, Hora4. Project selector em TaskCreateDialog: - Quando aberto DE dentro de um proyecto (<code>defaultProjectId</code> provided) → dropdown escondido, tarefa anexada automaticamente - Quando aberto DA página <code>/atividades</code> (sem <code>defaultProjectId</code>) → dropdown "Projeto" visível com todos os proyectosFicheiros: <li>- <code>/tmp/comercialrs_build/src/pages/Activities.tsx</code> — filtro <code>!t.projectId</code></li> <li>- <code>/tmp/comercialrs_build/src/pages/Tasks.tsx</code> — usa <code>MeetingCreateDialog</code></li> <li>- <code>/tmp/comercialrs_build/src/components/tasks/TaskCreateDialog.tsx</code> — formulário actividades com selector de proyecto</li> <li>- <code>/tmp/comercialrs_build/src/components/tasks/MeetingCreateDialog.tsx</code> — formulário reuniões com auto-fill CRM</li> <li>- <code>/tmp/comercialrs_build/src/components/tasks/ProjectKanbanBoard.tsx</code> — kanban 5 colunas</li>Status: ✅ RESOLVIDO<hr><h2>ComercialRS — Key Vault Notes (Jul 2026)</h2><h3>firecrawl Server</h3> <li>- ficheiro: <code>/var/www/comercialrs/firecrawl_server.py</code> (no VPS)</li> <li>- serviço: <code>firecrawl.service</code> (systemd)</li> <li>- porta: <code>9085</code></li> <li>- endpoint: <code>POST /functions/v1/firecrawl-extract-meeting</code></li> <li>- Teste local: <code>curl -X POST http://localhost:9085/functions/v1/firecrawl-extract-meeting -d '{"url":"..."}'</code></li> <li>- Teste Kong: <code>curl -X POST https://comercialrs.rochasalesseguros.com.br/functions/v1/firecrawl-extract-meeting ...</code></li><h3>Kong Config Active</h3> <li>- ficheiro: <code>/opt/rochasales/volumes/api/kong.yml</code> (MOUNTED into Kong container at <code>/var/lib/kong/kong.yml</code>)</li> <li>- NÃO use: <code>/docker/deploy-vps/kong.yml</code> (não está em uso)</li><h3>Rede Docker — IP Gateway</h3> <li>- Kong container está na rede <code>deploy-vps_default</code> → gateway = <code>172.23.0.1</code></li> <li>- Kong container também na rede <code>rochasales_default</code> → gateway = <code>172.28.0.1</code></li> <li>- Para aceder ao host (serviços como firecrawl:9085) → usar <code>172.23.0.1</code> (funciona do container Kong na rede deploy-vps_default)</li> <li>- <code>host.docker.internal</code> NÃO funciona neste ambiente</li></ul><hr><h2>Runbook: firecrawl-extract-meeting Retornando Erro (Jul 2026)</h2>Sintoma: Ao criar reunião em <code>/tasks</code> → cola link CRM → clica "Preencher" → aparece toast de erro da Edge Function.Checklist de diagnóstico (ordem):<code>`</code> 1. Testar Kong diretamente: curl -s -X POST https://comercialrs.rochasalesseguros.com.br/functions/v1/firecrawl-extract-meeting \ -H 'Content-Type: application/json' \ -d '{"url":"https://wa.me/5511999999999"}' Se der {"message":"An invalid response..."} ou timeout → vai para passo 2 Se der {"success": true, ...} → o problema é no browser (cache) → limpar cache ou hard refresh2. Testar firecrawl_server localmente no VPS: ssh root@31.97.243.106 curl -X POST http://localhost:9085/functions/v1/firecrawl-extract-meeting \ -d '{"url":"https://wa.me/5511999999999"}' Se não responder → firecrawl_server não está a funcionar: systemctl status firecrawl # Se inactive/dead → systemctl start firecrawl3. Verificar se firecrawl_server.py existe no VPS: ls -la /var/www/comercialrs/firecrawl_server.py # Se não existir → scp do build local: scp /tmp/comercialrs_build/firecrawl_server.py root@31.97.243.106:/var/www/comercialrs/firecrawl_server.py4. Verificar rota no Kong activo: grep -A5 'firecrawl' /opt/rochasales/volumes/api/kong.yml # Se não existir → adicionar manualmente (ver passo 5)5. Adicionar rota firecrawl ao Kong (se missing): # Editar /opt/rochasales/volumes/api/kong.yml # Adicionar ANTES do serviço "functions": - name: firecrawl url: http://172.23.0.1:9085 routes: - name: firecrawl-route paths: - /functions/v1/firecrawl-extract-meeting strip_path: false docker restart rochasales-kong-1 && sleep 86. Verificar rede Docker (se firecrawl não responde do container): docker inspect rochasales-kong-1 --format '{{range $net, $conf := .NetworkSettings.Networks}}{{printf "%s: %s\n" $net $conf.IPAddress}}{{end}}' # Kong na rede deploy-vps_default → gateway = 172.23.0.1 # Kong na rede rochasales_default → gateway = 172.28.0.1 # Testar: docker exec rochasales-kong-1 wget -q -O- http://172.23.0.1:9085/ ... <code>`</code>Nota: O ficheiro <code>/docker/deploy-vps/kong.yml</code> NÃO é usado pelo Kong em produção. Usar SEMPRE <code>/opt/rochasales/volumes/api/kong.yml</code>.<hr><h2>Runbook: Browser Mostra Erro Antigo Após Deploy (Jul 2026)</h2>Sintoma: O browser mostra mensagens de erro de versões anteriores do código, mesmo depois de fazer novo deploy.Causa: Cache do browser ou de CDN intermédio.Solução (nesta ordem): <code>`</code> 1. Hard refresh: Ctrl+Shift+R (Windows/Linux) ou Cmd+Shift+R (Mac)2. Se persistir, limpar cache do browser: Chrome: DevTools (F12) → Network → Disable cache ☑ → hard refresh3. Se ainda persistir, verificar se o bundle correcto está em produção: ssh root@31.97.243.106 grep -l 'firecrawl-extract-meeting' /var/www/comercialrs/assets/*.js # Deve mostrar o ficheiro JS correcto4. Verificar se o index.html referencia o bundle correcto: cat /var/www/comercialrs/index.html | grep 'main-' # Comparar com ls /var/www/comercialrs/assets/main-*.js <code>`</code><hr><h2>Runbook: useSyncExternalStore Error no Browser (Jul 2026)</h2>Sintoma: Página <code>/atividades</code> mostra <code>Uncaught TypeError: Cannot read properties of undefined (reading 'useSyncExternalStore')</code> ou ecrã branco.Causa: <code>manualChunks</code> no <code>vite.config.ts</code> a isolar <code>@hello-pangea/dnd</code> em chunk separado — a biblioteca precisa do contexto React.Solução: <code>`</code> 1. Editar /tmp/comercialrs_build/vite.config.ts 2. Remover TODO o bloco manualChunks (ou a entrada @hello-pangea/dnd) 3. npm run build 4. rm -rf /var/www/comercialrs/assets/* 5. cp -r dist/assets/* /var/www/comercialrs/assets/ 6. Actualizar hash no /var/www/comercialrs/index.html (se necessário) 7. Hard refresh no browser <code>`</code>O warning "Some chunks are larger than 500 kB" é normal — o bundle grande mas funcional é preferível a chunks separados mas quebrados.<hr>Última atualização: 2026-07-13<hr> Sincronização GitHub corrigida - Mon Jun 15 18:26:13 UTC 2026 Razão: GitHub Secret Scanning bloqueava commit 82fcac3 com token Discord Solução: novo commit limpo em cima </article> </div> </body></html>