Execuções
/dashboard/executions é onde se responde a pergunta operacional básica: o que rodou, e o que
falhou? Cinco abas, uma por tipo de execução.
As cinco tabelas parecem "execuções", mas registram fluxos diferentes. Procurar na aba errada devolve uma tela vazia que parece um bug — e está correta.
As cinco abas
| Aba | Registra | Pergunta que responde |
|---|---|---|
| Conectores | o SFA lendo uma fonte e gravando o canônico | "a sincronização do ERP rodou?" |
| Pipelines | a engine de pipeline executando | "por que o pedido não foi aprovado?" |
| Webhooks | o que chegou e o que o SFA enviou | "o parceiro recebeu o evento?" |
| Consumo externo | alguém de fora lendo o canônico | "o Wessel está mesmo puxando?" |
| Outbox | eventos de domínio publicados | "o evento chegou a sair?" |
Conectores e Consumo externo são sentidos opostos do mesmo dado — no primeiro o SFA é o destino, no segundo é a fonte. Ver Consumo externo do canônico.
Filtros: servidor vs cliente
Esta distinção importa e a tela a sinaliza:
- Status e período filtram no servidor. Mudá-los refaz a consulta e reinicia a paginação.
- A busca livre olha apenas a página carregada. É um refinamento visual, não uma busca no histórico.
Ou seja: para achar uma falha de três semanas atrás, amplie o período — digitar o nome do conector na busca não vai encontrá-la.
Drill-down
Duas abas abrem detalhe na própria linha:
- Conectores → os
SyncRecordLogdaquela execução: registro, status, operação e mensagem. É onde um erro de de-para aparece nomeado. Uma execução limpa pode não ter nenhum — o conector só grava log por registro quando há algo a relatar. - Pipelines → o trace passo a passo, com entrada, saída, logs e erro de cada nó.
O que cada status de conector quer dizer
| Status | Significa |
|---|---|
| Sucesso | leu a fonte inteira e gravou sem erro |
| Parcial | gravou dados, mas não leu tudo: a leitura foi interrompida, bateu no teto de páginas, ou houve erro em algum registro |
| Falhou | não deu para gravar nada (fonte fora, credencial inválida, conector desligado) |
| Interrompida | o processo da API caiu no meio; a execução é detectada e pode ser repetida |
| Cancelada | alguém mandou parar — ou a execução interrompida foi encerrada à mão |
Parar uma execução em andamento
O botão Parar, na linha da execução, registra um pedido. A leitura encerra ao terminar a página atual: o que já foi lido fica gravado, nada fica pela metade, e a execução termina como Cancelada com o motivo ("cancelada a pedido, depois de N páginas").
Enquanto isso o status mostra Cancelando… — clicar de novo não acelera. Se a fonte estiver no meio de uma página lenta, a parada só acontece quando aquela resposta chegar.
A leitura roda dentro do processo da API e não há ponto de aborto no meio de uma requisição HTTP. O que dá para escolher é não começar a próxima página — e é isso que o botão faz. Matar no meio deixaria lote gravado pela metade e uma execução dizendo uma coisa enquanto o dado faz outra.
Execução Interrompida é outro caso: ali não há processo nenhum rodando, então Cancelar fecha na hora, e Tentar novamente fecha e dispara outra.
Parcial não é falha, e os números ficam. Se a fonte cair na página 15 de 20, as 14 páginas já
gravadas continuam no banco e a execução termina como Parcial, com lidos / gravados / erros
reais e um log explicando onde parou. Antes de 2026-09-29 esse caso virava "Falhou" com 0 / 0 / 1,
como se nada tivesse acontecido — e, pior, escondia que 7.000 registros já estavam gravados.
Um 504, 503, 429 ou timeout numa página é tentado de novo (3 vezes, esperando 2s, 6s e 15s)
antes de interromper a leitura, e cada tentativa vira um aviso no log da execução. É o caso típico de
duas sincronizações pesadas no mesmo ERP ao mesmo tempo. Erro de configuração (401, 403, 404)
não é repetido: repetir não conserta credencial nem caminho errado.
Depois de uma parcial, Tentar novamente relê do começo. O que já estava gravado e não mudou entra como Ignorado (mesmo hash), então a segunda passada é mais barata que a primeira.
O trace é carregado sob demanda: a listagem vem sem os steps de propósito, porque output e
logs por step transformariam uma página de 25 execuções num payload de megabytes.
Reprocessamento
| Aba | O que o botão faz |
|---|---|
| Conectores | nova tentativa do mesmo conector (attempt + 1) |
| Webhooks · recebidos | re-emite o evento a partir do staging (mesma correlação) |
| Webhooks · enviados | reenvia o mesmo evento ao assinante |
| Outbox | volta o evento de FAILED para PENDING; o relay reenfileira |
No Outbox o botão só está ativo para eventos falhos — reprocessar um já publicado duplicaria um efeito que já aconteceu.
Ao vivo
A aba Conectores mantém uma conexão SSE e recarrega sozinha quando uma execução muda de estado, mas só na primeira página: numa página interna, reordenar linhas debaixo do cursor do usuário seria pior do que esperar. O indicador ao lado dos filtros mostra se a conexão está de pé.
Permissões
Cada aba exige a sua, e as que você não tem simplesmente não aparecem:
| Aba | Permissão |
|---|---|
| Conectores, Consumo externo | integration:read |
| Pipelines | pipeline:read |
| Webhooks | webhook:read |
| Outbox | outbox:read |
Reprocessar exige a permissão de escrita correspondente (integration:run, webhook:write,
outbox:reprocess).
Retenção
Só consumer_reads e api_key_usages expiram (60 dias, ADR-035).
As demais tabelas de execução crescem indefinidamente — se o volume incomodar, é uma decisão de
retenção ainda em aberto, não um comportamento configurado.