Selo de estado:
Preview(limite atual do produto) · Atualizado em 2026-10-04. Fonte de estado: matriz de estados do produto. Sem SLA.
Uma execução não é uma lista de tarefas: é um grafo. A Bronze lê a fonte; a Silver lê a Bronze; a Gold lê a Silver (ou várias). Declarar essas dependências é o que permite ao produto ordenar as tarefas e — mais importante — não fingir sucesso quando algo quebrou antes.
Onde a dependência é declarada#
Na etapa Transformações do assistente de pipeline,
cada etapa Silver/Gold diz de quem depende (depende de). A referência é a
tabela de destino da tarefa anterior (ex.: bronze:tb_vendas), não o nome do
arquivo ou da tabela de origem.
Na página da execução, a aba Grafo mostra as tarefas e as setas entre elas (acompanhar uma execução).
A porta de dependência (o que muda na prática)#
A camada seguinte NÃO roda quando a origem falhou
Se a Bronze de vendas falhou nesta execução, a Silver que depende dela não
executa — mesmo que a tabela Bronze exista no datalake com a carga do dia
anterior. Antes dessa regra, a Silver "passava" lendo dado velho e reportava um
número que não correspondia à carga do dia. Agora ela aparece como
bloqueada por dependência, com o motivo.
Isso vale para os dois executores (a execução agendada e a execução manual): a regra mora num único módulo e é a mesma nos dois caminhos.
Como o nome é resolvido#
Para decidir se uma tarefa depende de uma Bronze que falhou, o produto compara a referência declarada com as Bronzes da versão executada, nesta ordem:
| Resposta | Quando | O que acontece |
|---|---|---|
| Identidade | a referência é exatamente a tabela de destino da Bronze (sem acento, sem caixa) | é a dependência; falhou → bloqueia |
| Apelido | a referência casa com uma forma derivada da origem (o nome do arquivo, com ou sem extensão) e aponta para uma única Bronze | é a dependência; falhou → bloqueia |
| Ambíguo | o mesmo apelido casa duas Bronzes (ex.: clientes.csv e clientes.json) | o produto não escolhe: bloqueia se qualquer uma falhou e registra a ambiguidade |
| Inexistente | nenhuma Bronze casa | a tarefa não é bloqueada (não há origem falhada), mas a execução registra que a dependência declarada não existe — corrija a declaração |
Apelido nunca sobrepõe identidade. Se você quer previsibilidade total, declare sempre pela tabela de destino.
Boas práticas#
- Nomeie destinos sem colisão. Duas origens com o mesmo nome-base
(
clientes.csveclientes.json) geram apelidos ambíguos; dê destinos distintos (tb_clientes_crm,tb_clientes_erp). - Uma Gold que lê duas Silver declara as duas. A ordem de execução segue o grafo; a porta considera todas as origens declaradas.
- Falha a montante é falha do dia. Quando uma Bronze falha, trate a recuperação a partir dela; reexecutar só a Gold não traz dado novo.
Relacionado: Acompanhar uma execução · Recuperar uma falha · Publicar e versionar · Pipeline e medalhão.