Execuções — Programados, Executados, Manual
Acompanhamento das integrações em 3 sections: programados (próximas runs), executados (histórico real), manual (sob demanda). Badge Inicial mostra progresso da carga inicial.
1. Programados
Integrações com trigger=schedule ou file_polling. Lista quando a próxima execução está marcada.
Coluna Carga inicial mostra badge:
- Inicial · N docs (info azul): carga inicial em andamento
- Inicial · N docs (amarelo + ⚠): última run truncou no limite paginator — continua na próxima
- Inicial concluída (verde): transitou pra delta normal
- aguardando início: integração ativa mas ainda não rodou
2. Executados
Histórico real vindo de integration_executions (últimos 200 runs). Colunas:
- Data: timestamp do início
- Empresa / Integração: links
- Status: success, error, partial, running (com error_message truncado + tooltip)
- Duração: em ms/s/min
- Mensagens: received↓, sent↑, errors
Filtros: busca + select de status.
3. Manual
Integrações trigger=manual (executar sob demanda). Coluna "Executar Agora" inline + ver logs.
Links levam pra testar conexão
Link da coluna "Integração" leva pra /edi-hub/integracao/[id] onde há card Testar conexões — botões para testar source e destination separadamente. Útil quando uma execução falha com "Sem conexão de origem ativa" — você abre, vê a URL/protocolo e testa direto.
Por que minha execução esperou (ou avisou "host ocupado")?
Quando duas ou mais integrações apontam pro mesmo sistema de origem (mesmo host — ex.: o mesmo SAP), o Lefia serializa automaticamente o acesso: a segunda execução espera a vez (até 2 minutos) enquanto a primeira termina de puxar os dados. Isso protege o sistema do cliente — muitos ERPs (incluindo sandboxes SAP) rejeitam requisições simultâneas pesadas da mesma chave de API com erro 500.
Nos logs da execução:
Host X estava ocupado por outra execução — aguardei Ns pela vez.→ normal, a execução seguiu e terminou.Host X ocupado por outra execução (aguardei 120s). Nada foi perdido...→ a primeira execução demorou mais que a janela de espera. Nenhum dado foi perdido: o cursor não andou; rode de novo (ou aguarde o próximo agendamento) que a integração continua de onde parou.
Boas práticas: escalone os horários de integrações do mesmo sistema (não agende tudo pro mesmo minuto). A espera vale só pro tráfego contra a origem; o processamento interno roda sem trava, e integrações com origens diferentes nunca esperam uma pela outra.
Histórico de versões
- 1.4.0
#386: semáforo de execução POR HOST de conexão. Execuções simultâneas contra o mesmo host source (mesma API key/sandbox SAP) davam 500 na segunda enquanto a primeira puxa $expand pesado — max_parallel_executions é por integração, faltava coordenação cross-integração. Agora: lease em Postgres (host_execution_locks + RPCs atômicas acquire/release_host_lock, TTL 300s auto-limpa órfão de crash), seção crítica = só o fetchMessagesFromSap (lock solta no finally), segunda execução ESPERA a vez (poll 3s+jitter, teto 120s) e segue; no teto → erro amigável sem mexer no cursor. Fail-open se a infra do lock cair. Format-agnostic: chave = host normalizado da base_url (lib em src/lib/integrations/host-lock.ts). Por que tabela e não advisory lock: lock de sessão é connection-scoped, não sobrevive ao pool do Supabase. Segurança padrão #385 (RLS deny-all, SECURITY DEFINER + search_path, REVOKE PUBLIC, GRANT service_role). 17 testes novos, suíte 2903 verde.
6/10/2026 · updated
- 1.3.0
/execucoes 3 sections (Programados/Executados/Manual). Coluna data + badge Inicial + progresso carga inicial. Fix overflow tooltip botão Executar Agora. TestConnectionsCard novo em /edi-hub/integracao/[id]. i18n PT/EN/ES.
5/14/2026 · updated
- v1.2.0
2 commits: 1. (4529bfa) Warnings cron 1x/dia + validações create/update-integration - UI warning amber em ambos triggers (file_polling + schedule): "Plano atual roda cron 1×/dia. Intervalos <24h ficam registrados pra upgrade Pro." - Backend validação: schedule + mode=cron exige schedule_cron; mode=interval exige interval_value+unit; file_polling exige poll_directory+pattern. Retorna 400 antes de gravar row órfã. - Row órfã 'teste' (f382e5d5...) archived via MCP (hard delete bloqueado por FK em messages históricas). 2. (4398453) /execucoes refactor visual (pedido Bruno screenshot) - Cards de empresas → lista de integrações ativas (mesma aparência da tabela Próximas Agendadas) - Granularidade mudou: era por tenant, agora por integration (faz sentido pras ações inline) - Section "Próximas Agendadas": coluna Integração agora é link → /edi-hub/integracao/[id] (ícone ExternalLink + tooltip Editar) - Section "Integrações ativas": Empresa (link tenant) · Integração (link edit) · Trigger (badge + ícone) · Última execução · Stats (total/OK/erros) · Ações (ExecuteNowButton + Ver logs) - Filtros em ambas sections (in-memory client-side, sem reload): * Próximas Agendadas: search (empresa/integração) + select tipo * Integrações: search + select trigger + checkbox "Só com erros" - Novo client component executions-view.tsx (370 linhas) unifica as 2 sections + filtros - 22 chaves i18n novas: executions.integrations.* (8), executions.triggers.* (5), executions.filters.* (5), executions.scheduled.editIntegration (1) Merge final: 3b1c529 → ef198c5. 8 arquivos, +594/-196.
5/13/2026 · updated
- v1.1.0
Section "Próximas execuções agendadas" no topo de /execucoes: - Lista integrations com trigger_type IN ('schedule','file_polling') AND status='active' do env selecionado (cookie selected_env_name). - Colunas: Empresa (link pra /execucoes/empresa/[id]) · Integração · Tipo (Agendado/Polling com ícone CalendarClock/FolderClock) · Frequência humanizada · Próxima execução. - Sort: next_execution_at ASC (com next primeiro; sem next agrupado por nome no final). - Frequência humanizada: * schedule_cron: "cron · 0 */6 * * *" * schedule_interval_value+unit: "a cada {n} {unit}" * poll_interval_seconds: "a cada 60s" / "a cada 5min" / "a cada 2h" conforme magnitude - Overdue (next_execution_at < now) marcado em vermelho com AlertCircle. - Empty state: "Nenhuma integração agendada/polling ativa em {env}". - Date.now() capturado no server render (nowMs) — evita falso positivo react-hooks/purity. i18n: namespace novo executions.scheduled.* com 15 chaves (PT/EN/ES). eslint.config.mjs: filter react-hooks/purity estendido pra cobrir src/app/(dashboard)/**/page.tsx (era só (admin)/admin). Mesmo pattern de RSC com await supabaseAdmin — antes disparava falso positivo em pages do dashboard. Commit: e3ac3e6 → merge 3b1c529 em main.
5/13/2026 · updated