Central de AjudaVoltar ao app
Voltar para Central de ajuda
FT-EXECUCOES· 1.8.0Operação

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.

Atualizado em 09/11/2026
A página /execucoes mostra 3 sections distintas:

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 /mapeamentos/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 limita quantas leituras correm ao mesmo tempo nesse servidor (padrão 2, 1 no sandbox público da SAP; vale o menor valor entre as conexões do servidor, em Leituras simultâneas no servidor): a execução que encontra todas as vagas ocupadas espera a vez (até 2 minutos). 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.

Executar agora que lê tudo da origem (28/09/2026)



Quando a integração vai ler tudo da origem — "Completa a cada execução" sem filtro, ou REST sem cursor nem data de corte — o Executar agora abre uma confirmação na própria página antes de rodar, dizendo que todos os registros da origem serão lidos e enviados ao destino. Nada roda até você confirmar; cancelar não muda nada. Para não ver mais o aviso, limite a leitura na configuração da integração (filtro ou data de corte). Quando a entidade OData tem parâmetros que limitam a leitura (ex.: as datas = ontem), o aviso mostra quais são e diz que a execução lê tudo o que a origem devolve para esses parâmetros, não tudo da origem.

Carga inicial sem data de corte (29/09/2026)



No modo "Carga inicial + delta", a carga inicial parte da data de corte. Sem ela (e sem cursor gravado), não há de onde começar e nada é lido. Nessa situação a integração aparece em Programados com o selo Sem data de corte na coluna da carga inicial, o agendador não a executa (não aparece execução com erro) e o Executar agora avisa sem executar. Ao retomar uma integração pausada nessa situação, a confirmação avisa antes. Para liberar, preencha a data de corte na configuração da integração: só o que mudou a partir dessa data é lido.

Motivo da falha e agendamento pausado por credencial recusada (28/09/2026)



Toda execução com erro mostra o motivo em Executados: um rótulo curto (ex.: Credencial recusada pela origem, Origem indisponível, Configuração incompleta) e, abaixo, o mesmo texto do log da execução.

Credencial recusada repetida pausa o agendamento. Quando a origem recusa a credencial (HTTP 401, login do banco Oracle recusado, ou o servidor de token OAuth recusando o cliente ou a concessão — invalid_client/invalid_grant; escopo inválido ou tipo de concessão não suportado é configuração e não pausa) em N execuções agendadas seguidas (padrão 3; desde a última retomada ou troca de credencial; execução manual, webhook e evento não contam), o Lefia para de tentar a cada intervalo: tentar de novo só repete a falha e pode bloquear a conta na origem. Só o agendamento pausa — a integração continua ativa, e Executar agora, webhook e evento seguem. O administrador da empresa recebe um aviso, e a integração mostra Agendamento pausado com dois botões:

  • Renovar credencial — abre a edição da conexão. Ao salvar a credencial nova — ou ao concluir o Reconectar de uma conexão OAuth —, o agendamento volta sozinho.
  • Retomar agendamento — tenta de novo sem trocar a credencial (ex.: a conta foi desbloqueada na origem).


Reativar a integração (Pausar → Retomar) também retoma o agendamento. Falha passageira — origem fora do ar (5xx), rede, timeout, origem ocupada — nunca pausa, nem HTTP 403 (acesso negado: pode ser limite de taxa ou firewall; aparece como Acesso negado pela origem, com o motivo). A pausa fica registrada na trilha de auditoria.

OData sem $metadata. A execução OData decide pelo $metadata do serviço quais navegações ler. Se ele não puder ser lido (serviço fora do ar, credencial recusada, acima de 50 MB), a execução para antes de ler os documentos, com o motivo — nunca segue lendo menos navegações, o que mudaria a saída do mapeamento. O cursor não anda; a próxima execução tenta de novo. O limite de 5 MB vale só para cadastrar mensagem no catálogo.

Quem decide. A política é da empresa, na seção Alertas das Configurações: quantas falhas seguidas (1 a 20, padrão 3) e o que fazer — pausar o agendamento e avisar (padrão) ou não pausar, só avisar. O aviso vai para o sino do administrador e para o e-mail e o Slack configurados na mesma seção (sem canal, só o sino). Com só avisar, o aviso sai uma vez por sequência de falhas; um sucesso ou a retomada zera. Cada integração pode sobrescrever na edição (Execução › Avançado › Credencial recusada repetida): padrão da empresa, não pausar, ou pausar depois de 1 a 20 falhas — o mesmo campo no assistente e na criação manual.

Selo "Há mais páginas". Na lista de programados e de manuais, a integração que lê em páginas e ainda não chegou ao fim dos dados mostra este selo. Ele some sozinho quando uma execução alcança o fim; execução com 0 importados entre páginas não significa que terminou.

Executar agora sem depender da página (10/10/2026)



O Executar agora responde na hora e a execução continua sozinha, mesmo que você feche a página ou perca a conexão:

  • Integração na fila de trabalho: a leitura entra na fila e um processador começa em seguida. Se já houver uma leitura na fila para a integração, o pedido reaproveita essa leitura em vez de criar outra.
  • Demais integrações: a execução é criada e roda logo depois da resposta.


Acompanhe em Execuções ativas agora. Se a execução for interrompida no meio, o histórico mostra até onde ela chegou e o que ela gravou e não processou é retomado automaticamente em até 10 minutos.

Histórico de versões

  • 1.8.0

    A tela de Execuções mostra o selo "Há mais páginas" nas integrações cuja leitura em páginas ainda não chegou ao fim dos dados (programadas e manuais). O selo some sozinho quando uma execução alcança o fim.

    10/10/2026 · updated

  • 1.7.0

    Pausa do agendamento por credencial recusada vale também para origens com OAuth 2.0: quando o servidor de token recusa o cliente ou a concessão (invalid_client, invalid_grant, ou 401), a execução é registrada como credencial recusada e conta para a pausa. Escopo inválido ou tipo de concessão não suportado é configuração e não pausa; servidor de token fora do ar é passageiro.

    03/10/2026 · updated

  • 1.6.1

    Correção da pausa do agendamento por credencial recusada. Salvar a credencial nova (ou reconectar o OAuth) sempre recomeça a contagem, mesmo antes de o agendamento pausar: uma execução que já estava rodando com a credencial antiga e falha depois da troca não pausa mais o agendamento (antes o cliente corrigia e mesmo assim precisava clicar em Retomar). Login SFTP/FTP recusado não entra na regra: o agendamento ainda não lê origem SFTP/FTP, e a versão 1.6.0 prometia isso por engano — a regra vale para HTTP 401 (OData, REST) e login do Oracle recusado. Falha da própria regra agora aparece no painel de erros, sem interromper a execução.

    03/10/2026 · updated

  • 1.6.0

    Execução com falha mostra o motivo. Toda execução que termina em erro grava o motivo — o mesmo texto do log — e um código estável (credencial recusada, acesso negado, origem indisponível, origem ocupada, leitura interrompida, configuração incompleta, falha ao gravar, execução interrompida, erro inesperado). A lista de Execuções, a tela da empresa e o painel da integração mostram o código traduzido e o texto. Antes, uma origem REST que respondia 401 deixava a execução em erro sem motivo (só no log). Credencial recusada repetida: a empresa decide na seção Alertas (quantas falhas seguidas, padrão 3, e pausar ou só avisar; cada integração pode sobrescrever em Execução › Avançado). Com pausar, depois de N execuções agendadas seguidas com a mesma credencial recusada pela origem (HTTP 401, login do Oracle/SFTP/FTP recusado; 403 aparece como acesso negado e não pausa), o agendamento para de tentar; o aviso vai para o sino do administrador e para o e-mail/Slack da seção Alertas (com só avisar, uma vez por sequência); a integração mostra "Renovar credencial" e "Retomar agendamento". Salvar credencial nova ou reconectar o OAuth retoma sozinho. Falha passageira (5xx, rede, timeout) segue tentando como antes.

    28/09/2026 · updated

  • 1.5.1

    Correção: integração em "Carga inicial + delta" sem data de corte (e sem cursor) não vira mais erro a cada rodada do agendador. Sem ponto de partida a carga inicial não lê nada; agora o agendador simplesmente não a executa (sem execução com erro nem registro de erro), a tela de execuções mostra o selo "Sem data de corte" na coluna da carga inicial, o "Executar agora" avisa o que fazer sem executar e retomar uma integração pausada nessa situação avisa antes. Preencher a data de corte na configuração libera a execução.

    25/09/2026 · updated

  • 1.5.0

    Aviso antes de executar leitura de tudo da origem (decisão de 26/09: avisar, não recusar). Regra única unboundedRead (lib/integrations/unbounded-read): OData/REST em "Completa a cada execução" sem filtro, ou REST sem cursor nem data de corte. Executar agora: o servidor devolve 409 unbounded_read sem executar nem registrar e a tela confirma num ConfirmDialog (não confirm() do navegador); confirmado, repete com acknowledgeUnboundedRead. Agendador (cron) não é bloqueado — o aviso aparece na configuração (assistente, criação manual e edição) ao escolher o modo.

    25/09/2026 · updated

  • 1.4.1

    Correção: "Próxima execução" só existe em integração agendada; o "Executar agora" de integração manual não grava mais próxima execução e a troca de gatilho zera a coluna. Tempos em ms não aparecem mais em dobro.

    24/09/2026 · updated

  • 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.

    10/06/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.

    13/05/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.

    13/05/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.

    13/05/2026 · updated