O que o Weave verifica

Descrição

O Weave lê a configuração que o seu projeto já salvou e o registro de como os fluxos de trabalho dele foram executados nos últimos 30 dias, e relata o que encontra: uma etapa cuja alocação não tem nada a alocar, um fluxo de trabalho cuja estrutura salva lista a mesma etapa duas vezes, um fluxo de trabalho cuja última execução falhou, uma etapa cuja saída contém muito menos linhas do que costuma conter. Ele apenas lê — nada do que relata altera uma etapa, e ele nunca executa o seu fluxo de trabalho.

Nenhum modelo de IA está envolvido. Cada verificação é uma regra fixa e cada frase é escrita de antemão, então um relatório não custa nada para ser gerado, não importa quantas vezes você o solicite.

Nota

As constatações podem ser acessadas pela API da plataforma, e a guia Weave do projeto lista todas as constatações do projeto.

Três respostas, não duas

A maioria das verificações no PlaidCloud tem duas respostas: a sua configuração está correta ou é recusada. O Weave tem uma terceira, e é ela que vale a pena entender.

Resposta	O que significa
O Weave notou …	O Weave verificou isto e encontrou um problema.
(nada é dito)	O Weave verificou isto e não encontrou nada de errado.
O Weave não verificou …	O Weave não conseguiu avaliar isto de forma alguma.

A terceira existe porque o silêncio é ambíguo. Quando você cria uma etapa de alocação, o PlaidCloud permite salvá-la antes de você preencher o mapeamento de colunas — você ainda está construindo a etapa, e recusar o salvamento impediria o seu trabalho. Um monitor que lesse esse mesmo mapeamento vazio poderia facilmente relatar a etapa como saudável. Ela não está saudável; está inacabada, e ninguém a examinou.

Por isso o Weave diz isso. Uma etapa que ele não conseguiu avaliar é relatada como não verificada, com o motivo, e nunca é contada, ordenada ou colorida como se tivesse passado.

Há uma quarta coisa que o Weave pode dizer, e ela não é uma resposta sobre a sua etapa: O Weave não tem regra para …. Isso significa que o Weave não tem verificação para esse tipo de coisa e nunca o avaliou. Ao contrário de “não verificou”, nada que você faça na etapa produzirá um veredito, então vale a pena distinguir os dois: termine uma etapa não verificada e o Weave a avaliará; uma etapa para a qual ele não tem regra continua sem avaliação, por mais que você a altere.

Como é um relatório

Um relatório começa com um resumo que informa o seu próprio denominador, para que você veja quanto do projeto ele cobre:

Weave fully checked 3 of the 417 steps and workflows in "Cost Model", and found 1
problem in the parts it could judge. 1 more it hasn't fully checked.
Weave has no rule for 412 steps and 1 workflow it looked at, so they have not been
judged either way.

Weave noticed the step "Spread Overheads": No driver split value column found. One
driver column must have the role "Split Value".
Weave hasn't checked the step "Regional Split" — its column mapping is empty.

Quando um projeto tem tabelas gravadas em um agendamento ou com um limite de atualização definido, a primeira linha as conta separadamente: O Weave verificou totalmente 31 das 36 etapas e fluxos de trabalho, e 3 das 4 tabelas que devem ser mantidas atualizadas, em “Finance”, e encontrou 2 problemas nas partes que conseguiu avaliar.

A fração na primeira linha é intencional. Três etapas verificadas e sem problemas não é a mesma afirmação que um projeto sem problemas, e a linha de abertura carrega a sua própria escala para que não possa ser citada sem ela. “Nas partes que conseguiu avaliar” está ali pelo mesmo motivo: quando algo foi avaliado só em parte, os problemas encontrados não podem ser atribuídos às etapas que a linha acabou de chamar de verificadas. A segunda linha informa aquilo para o que o Weave não tem regra alguma e diz abertamente que esses itens não foram avaliados em nenhum sentido — e não que nenhuma verificação era necessária.

Como o Weave sabe

Cada constatação tem um link Como o Weave sabe abaixo dela, que abre um painel mostrando como o Weave chegou a ela:

• A verificação — o que a regra testa, em palavras simples, com os limites que usa, como quantas execuções anteriores servem de comparação para uma contagem.
• As evidências — os valores que a verificação usou. Para uma contagem de linhas que mudou, são a contagem mais recente, a média das execuções anteriores, quanto a contagem costuma variar de uma execução para outra e o intervalo fora do qual o Weave a relata.
• De onde veio — a execução, o histórico de execuções, as configurações salvas da etapa, o evento agendado ou a tabela de onde as evidências foram lidas. Um item exibido como link abre o local onde você o examinaria, como o fluxo de trabalho ou o Explorador de tabelas.
• O que o Weave não verificou — o que a regra deixa de fora. Isso nunca fica vazio: uma verificação de que uma tabela foi gravada no prazo, por exemplo, não examina o que foi gravado.

Para uma constatação que o Weave não conseguiu verificar, o painel mostra a verificação e o motivo pelo qual ela não pôde ser executada, sem evidências.

O painel informa apenas o que você pode ver. Uma etapa, um fluxo de trabalho ou uma tabela que a sua função oculta é listado como algo que você não pode abrir, nunca pelo nome, e quando a última execução de um fluxo de trabalho falhou em etapas que você não pode abrir, as evidências contam essas etapas em vez de nomeá-las. Nenhuma IA participa da montagem do painel.

O painel aparece na guia Weave e em uma revisão. O resumo escrito por IA de uma revisão também tem um, informando que foi escrito por IA, a partir de quantas constatações, e o que o Weave verificou antes de exibi-lo. Uma revisão que um assistente de IA executa pelo PlaidCloud MCP não inclui o painel.

O que o Weave verifica hoje

Mapeamento de colunas de alocação. Para uma etapa Allocation with Dimension ou Allocation Split, que exista uma coluna numérica a alocar, um valor de direcionador numérico pelo qual alocá-la, uma hierarquia onde for necessária e — no caso de uma divisão — um numerador e um denominador que indiquem uma coluna que a tabela de origem realmente tem. São as mesmas verificações executadas quando você salva a etapa, lendo o que já foi salvo. O salvamento também verifica a própria dimensão de atribuição — que ela exista e que tenha exatamente uma propriedade de direcionador —, o que o Weave não faz; assim, uma etapa cujo salvamento é recusado por esse motivo não gera nenhuma constatação do Weave.

Expressões das etapas. Para qualquer etapa que as contenha, que toda expressão que você escreveu — em uma coluna de destino, na cláusula Subset ou na cláusula Secondary Filter — ainda compile. Uma constatação informa a coluna ou a cláusula para que você saiba qual abrir e mostra o erro, como Syntax error at line 1, position 280. A própria expressão fica em Como o Weave sabe, para que uma expressão longa não esconda o erro. São as mesmas verificações executadas quando você salva a etapa.

Dois casos que o Weave relata como não verificados em vez de avaliá-los:

• Uma expressão que lê uma variável. Uma etapa pode pertencer a mais de um fluxo de trabalho, e cada fluxo de trabalho pode definir uma variável com um valor diferente — ou nem defini-la. A verificação no salvamento sabe a partir de qual fluxo de trabalho você está salvando; uma varredura não sabe. Em vez de escolher um e arriscar dizer que uma expressão funcional está quebrada, o Weave relata a etapa como não verificada quando a variável não está definida em todos os lugares ou está definida com valores divergentes. Um fluxo de trabalho que a sua função não mostra a você conta da mesma forma: o Weave também não consegue ler as variáveis dele, então não afirmará que a etapa está de acordo. Quando todos os fluxos de trabalho concordam, ele avalia a etapa normalmente.
• Filtros e listas de colunas que esta verificação não lê. Alguns tipos de etapa guardam um filtro ou uma segunda lista de colunas em uma parte do formulário que a verificação de expressões nunca leu — as junções de duas tabelas e Lookup, as divisões de alocação, Generate Batch e SAP Post Journal Entry. O salvamento dessas etapas sempre ignorou esses campos, então o Weave não aprova a etapa com base na metade que consegue ler: ele a relata como não verificada. As etapas Junção de várias tabelas e Delete são relatadas da mesma forma, porque a configuração delas não está em um formato que esta verificação consiga compilar.

Algo listado duas vezes em um fluxo de trabalho. Que nenhuma etapa e nenhum fluxo de trabalho aninhado apareça mais de uma vez no mesmo fluxo de trabalho, e que duas pastas com o mesmo pai não tenham o mesmo identificador.

Etapas que podem ser executadas antes de a tabela que leem ser gravada. Em um fluxo de trabalho avançado, que toda etapa que lê uma tabela seja executada depois da etapa do mesmo fluxo de trabalho que a grava, por meio dos conectores na tela. O Weave verifica isso independentemente de o fluxo de trabalho já ter sido executado. Uma constatação indica uma dessas etapas e a etapa depois da qual ela deveria ser executada, e informa quantas etapas são afetadas; as tabelas são listadas em Como o Weave sabe. Uma etapa que a tela já executa cedo demais é relatada separadamente. O Weave relata o fluxo de trabalho como não verificado quando uma etapa executa outro fluxo de trabalho ou usa tabelas que ele não consegue acompanhar, e não avalia uma tabela que mais de uma etapa, ou outro fluxo de trabalho, também grava. Para revisar e adicionar os conectores ausentes, use Sincronizar dependências na tela. Se uma etapa deve ler a saída da execução anterior, marque a constatação como esperada.

Como os seus fluxos de trabalho foram executados. O Weave lê as execuções de cada fluxo de trabalho dos últimos 30 dias — até as vinte execuções mais recentes de cada fluxo de trabalho — e avalia a mais recente em relação às anteriores. Para as comparações de fim de mês e de dia da semana abaixo, ele também lê algumas execuções mais antigas dos últimos 180 dias. Toda comparação é feita com o próprio histórico do fluxo de trabalho, nunca com o de outro fluxo de trabalho.

• Falha na última execução. Um fluxo de trabalho cuja execução mais recente falhou é relatado, com a data da falha e, quando as execuções anteriores também falharam, quantas seguidas e desde quando.

• Execução mais lenta que o normal. Uma execução que terminou, mas cujas etapas, somadas, levaram mais tempo do que as execuções concluídas anteriores do fluxo de trabalho permitem — mais de dois desvios-padrão acima da média delas e pelo menos 5% acima dela (nunca menos de um segundo, para que um fluxo de trabalho rápido não seja relatado por alguns milissegundos). O tempo é a soma das etapas; portanto, em um fluxo de trabalho que executa etapas em paralelo, ele é maior do que o relógio mostrou. Uma execução que terminou mais rápido não é relatada.

• Etapa mais lenta que o normal. Uma etapa que levou mais tempo na sua execução concluída mais recente do que nas execuções concluídas anteriores naquele fluxo de trabalho, pelo mesmo critério de uma execução lenta. É assim que o Weave identifica a etapa por trás de uma execução lenta. Uma etapa presente em vários fluxos de trabalho é avaliada separadamente em cada um. O tempo vai do início ao fim da etapa: o Weave não separa o trabalho da própria etapa do tempo gasto em espera, como em um data warehouse ocupado.

• As execuções ficaram mais lentas. Uma lentidão que persistiu. Quando as execuções mais lentas passam a ser a maioria das execuções anteriores com que uma execução é comparada, uma execução lenta deixa de parecer incomum; por isso, esta verificação compara metades. O Weave lê as últimas 20 execuções do fluxo de trabalho nos últimos 30 dias, mantém as que foram concluídas e as divide em uma metade mais antiga e uma mais recente, conforme o horário de início. Ele relata o fluxo de trabalho quando o tempo mediano da metade mais recente é pelo menos 25% e pelo menos 30 segundos maior que o da metade mais antiga, e a execução mais recente levou mais tempo em pelo menos 85% dos pares formados por uma execução mais recente e uma mais antiga. O tempo é a soma das etapas, como em uma execução lenta. O Weave precisa de pelo menos 12 execuções concluídas distribuídas por pelo menos 14 dias, então um fluxo de trabalho executado mais de cerca de 20 vezes em duas semanas não é verificado. Execuções com falha e interrompidas não são contadas; uma execução que continuou após uma etapa com falha é contada. A constatação indica até três etapas que você pode abrir cujo tempo mediano mais cresceu, e a frase dela permanece a mesma enquanto a lentidão durar, para que você não seja avisado de novo após cada execução.

• Linhas de destino diferentes das execuções anteriores. Uma etapa cujas tabelas de saída continham muito mais ou muito menos linhas após a última execução do que após as execuções anteriores naquele fluxo de trabalho, pelo mesmo critério (e por pelo menos uma linha). A contagem é o que as tabelas contêm; portanto, uma etapa que anexa linhas é avaliada pelo total crescente. Uma etapa presente em vários fluxos de trabalho é avaliada separadamente em cada um.

• Junção duplicou mais linhas que o normal. Uma junção interna, à esquerda ou à direita que gravou mais linhas para cada linha da sua tabela principal do que após as execuções anteriores naquele fluxo de trabalho — mais de dois desvios-padrão acima da média delas e por pelo menos 5% dela. A tabela principal é a Tabela A em uma junção interna ou à esquerda e a Tabela B em uma junção à direita. Mais de uma linha gravada por linha da tabela principal significa que algumas das chaves de junção dela aparecem em mais de uma linha da outra tabela, de modo que as linhas que as contêm foram gravadas mais de uma vez. O Weave relata apenas um valor acima de 1,00, e somente quando está acima do nível habitual da junção; assim, uma junção que grava várias linhas por linha por design só é relatada se esse número aumentar. Em uma junção interna, apenas as chaves que se repetem na Tabela B são percebidas. Uma junção com menos de quatro execuções anteriores que registraram as linhas da tabela principal é relatada como não verificada.

  Uma junção que agrega, ou que usa Distintos, fatiamento (Limites) ou um Secondary Filter, é relatada como não verificada, porque cada um desses recursos altera a própria contagem de linhas. O mesmo vale para uma junção cuja tabela principal não tem contagem de linhas registrada, como uma visão. As linhas da tabela principal são as registradas quando ela foi gravada pela última vez, antes do filtro da etapa sobre ela. Um filtro que mantém uma proporção diferente das linhas a cada execução também altera o valor e pode ser relatado. Uma alteração feita na tabela principal de outra forma, ou por uma etapa executada ao mesmo tempo, não é percebida. Junções externas completas, cruzadas e de várias tabelas não são verificadas, e um Lookup não pode gravar uma linha mais de uma vez.

• Valores vazios diferentes das execuções anteriores. Uma coluna da tabela de saída de uma etapa que ficou vazia em uma proporção de linhas muito maior ou menor do que após as execuções anteriores da etapa — mais de dois desvios-padrão da proporção habitual e a pelo menos cinco pontos percentuais dela. Cada tabela que uma etapa grava é avaliada pelas suas próprias linhas.

• A importação não encontrou arquivos. Uma etapa de importação cuja execução concluída mais recente não encontrou arquivos no caminho de onde lê. A etapa termina com um aviso em vez de falhar, e cria a tabela de destino vazia ou não carrega nada, então as etapas seguintes não têm nada dela para ler. A constatação indica o fluxo de trabalho e o caminho, não precisa de execuções anteriores e desaparece quando uma execução encontra arquivos. Uma etapa presente em vários fluxos de trabalho é avaliada separadamente em cada um, e em um fluxo de trabalho que você não pode abrir o caminho não é exibido. O Weave não consegue distinguir uma pasta vazia de propósito de um arquivo ausente: se uma pasta vazia é normal ali, um Arquiteto do projeto pode marcar a constatação como esperada, e o Weave deixa de relatá-la para essa etapa nesse fluxo de trabalho, qualquer que seja o caminho. Uma execução registrada antes de esta verificação existir não mantém o texto do aviso, então a etapa dela é relatada como não verificada até ser executada novamente.

Fins de mês e dias da semana. Para um fluxo de trabalho ou uma etapa executado no máximo uma vez por dia, uma execução que essas verificações relatariam é dispensada quando está em linha com pelo menos quatro execuções anteriores no mesmo tipo de dia, dos últimos 180 dias, que não variam mais, em relação ao seu tamanho, do que as execuções anteriores em outros dias. Os tipos de dia são o último dia do mês, o primeiro dia do mês e, nos demais casos, o mesmo dia da semana. Assim, uma carga de fim de mês que é sempre pesada, ou uma carga que sempre é leve às segundas-feiras, não é relatada quando essas execuções são mais estáveis, em relação ao seu tamanho, do que as dos outros dias. O calendário só dispensa execuções: nunca relata uma que essas verificações aprovariam. Os dias são contados em UTC, e feriados e calendários de dias úteis não são levados em conta. Um fluxo de trabalho ou uma etapa executado mais de uma vez em um dia, incluindo uma execução com falha e a sua reexecução, é comparado com as execuções anteriores como antes.

Uma linha de base precisa de pelo menos quatro execuções anteriores. Com menos, o fluxo de trabalho é relatado como não verificado quanto ao tempo de execução, e as suas etapas como não verificadas quanto às linhas e aos valores vazios, cada um informando quantas execuções concluídas teve, em vez de ser avaliado com base em pouco histórico. Uma etapa que grava uma tabela, mas cujas execuções registradas não trazem contagens de valores vazios, também é relatada como não verificada quanto a eles. Uma etapa que não grava nenhuma tabela, como uma que envia um e-mail ou exporta um arquivo, não é verificada quanto a linhas ou valores vazios. Um fluxo de trabalho que não foi executado nos últimos 30 dias é relatado como não verificado, assim como um cujo histórico de execuções não pôde ser lido — nenhum dos dois é relatado como saudável. Em um projeto com Acesso a linhas declarado, as verificações de linhas, de junção, de valores vazios e de distribuição de valores não se aplicam a quem tem as leituras filtradas: cada uma é medida sobre a tabela inteira, então uma constatação informaria essas pessoas sobre linhas fora da concessão delas. Consulte Contagens de linhas e tamanhos de tabelas.

O que a última execução de uma etapa alterou. Para cada tabela que a última execução de uma etapa gravou, o Weave compara a tabela como a execução a deixou com a tabela como estava antes do início da execução, então não precisa de histórico de execuções anteriores.

• Valores distribuídos de forma diferente de antes da última execução. Uma coluna cujos valores se distribuem ao longo do intervalo de forma muito diferente após a execução em relação a antes dela. A constatação mostra uma pontuação de deslocamento: 0 significa que a distribuição não mudou, e 0,25 ou mais é uma grande mudança, que é quando o Weave a relata. Apenas colunas com números decimais são comparadas. Colunas de números inteiros costumam ser códigos, períodos ou indicadores, como um número de conta ou um mês, e a distribuição delas muda toda vez que novos períodos são carregados. Valores vazios não fazem parte da distribuição; a verificação de valores vazios acima cuida deles.

“Antes da execução” é a última versão da tabela que continha linhas. Uma versão deixada vazia por uma execução que falhou no meio do caminho é ignorada, então a primeira execução bem-sucedida após uma falha é comparada com os últimos dados válidos.

A execução de uma etapa é relatada como não verificada, com o motivo, quando uma tabela que ela gravou:

• tem Acesso a linhas declarado nas suas colunas;
• continha mais de 5.000.000 de linhas antes ou depois da execução;
• levou mais de 10 segundos para ser comparada;
• não mantém mais a versão de antes da execução — alguns lakehouses mantêm versões anteriores de uma tabela por 7 dias, então uma tabela regravada com frequência menor que semanal não tem com o que ser comparada; ou
• foi preenchida pela primeira vez nessa execução.

Um projeto cujo lakehouse não mantém histórico de versões não é avaliado por esta verificação.

Valores deixados vazios por uma conversão de tipo. Cada coluna que uma etapa Extract grava tem um tipo, como texto, inteiro ou data, e a etapa converte cada valor para ele. Em um lakehouse StarRocks, um valor que não pode ser convertido, como N/A indo para uma coluna de inteiros, é armazenado vazio, e a execução termina sem erro. Depois que uma etapa Extract é executada no StarRocks, o Weave conta, para cada coluna cuja conversão pode perder valores, os valores de entrada que ainda não estavam vazios e quantos deles saíram vazios, e relata cada coluna em que isso aconteceu. A constatação mostra a contagem e o tipo da coluna. Ele avalia a execução concluída mais recente da etapa em cada fluxo de trabalho, então não precisa de execuções anteriores.

• Valores que já estavam vazios na entrada não são contados. Texto em branco é, porque é armazenado vazio em uma coluna de número ou de data.
• Uma coluna cuja conversão não pode perder um valor, como números inteiros indo para uma coluna decimal, não é contada, nem uma coluna sem valores vazios após a execução.
• Se a contagem levar mais de 30 segundos, ou se as linhas que o Weave conta não corresponderem às linhas que a etapa gravou, a execução é relatada como não verificada, e o Weave conta novamente na próxima vez que a etapa for executada.
• Apenas etapas Extract no StarRocks são verificadas. Uma etapa que usa um Secondary Filter ou agrupa por uma expressão é relatada como não verificada, assim como uma que usa Distintos ou fatiamento (Limites) quando uma coluna pode perder valores, porque o Weave não consegue contar as linhas dela novamente sem a conversão.
• Se a etapa deve deixar esses valores vazios, um Arquiteto do projeto pode marcar a constatação como esperada.
• Assim como as verificações de linhas e de valores vazios, ela não se aplica a quem tem as leituras filtradas pelo Acesso a linhas.

Eventos agendados. Para um fluxo de trabalho com eventos agendados, o Weave compara cada evento com as execuções que ele iniciou e com o job no cluster que o dispara. Cada horário é considerado no fuso horário do próprio evento, e um disparo é avaliado 15 minutos após o vencimento, para dar tempo de o job iniciar.

• Cronograma do evento agendado inválido. Um evento habilitado cujo agendamento não pode ser lido.
• A execução agendada não foi iniciada. Um evento habilitado que venceu sem iniciar uma execução — desde a última vez que iniciou uma, ou desde que foi salvo, se nunca iniciou. Quando o cluster consegue informar, o Weave acrescenta se o cluster nunca disparou o evento ou se o job disparado falhou. A constatação indica a última execução que o evento iniciou, ou o horário em que foi salvo, para que continue sendo uma única constatação enquanto o evento permanecer com o mesmo defeito. Um evento salvo após o vencimento do disparo não é avaliado por esse disparo.
• O evento agendado venceu durante uma execução. Um evento que venceu enquanto o fluxo de trabalho ainda estava em execução, então nenhuma execução foi iniciada naquele momento. Um evento agendado nunca inicia uma segunda execução de um fluxo de trabalho que já está em execução; isso é relatado uma vez para que um agendamento mais apertado que as execuções do fluxo de trabalho não perca disparos sem que ninguém perceba.
• Evento agendado fora de sincronia com o cluster. Um evento e o job dele no cluster que divergem: um evento habilitado sem job, ou com o job pausado; um evento desabilitado cujo job não está pausado; ou um job configurado com um agendamento ou fuso horário diferente do que o evento mostra. Quando o cluster não pode ser lido, o fluxo de trabalho é relatado como não verificado quanto aos seus eventos agendados.

Um evento que parou de iniciar execuções não tem um fim de execução para avisar você sobre isso, então ele aparece na guia Weave em vez de em uma mensagem.

Tabelas gravadas em um agendamento. Para uma tabela que um fluxo de trabalho com um evento agendado habilitado grava, o Weave verifica se a tabela foi gravada desde o último vencimento do agendamento. Uma tabela conta como gravada quando uma etapa que a grava termina. O Weave não examina os dados da tabela, então não percebe uma carga feita fora das etapas do projeto. Assim como nas verificações de eventos agendados, cada agendamento é lido no fuso horário do seu evento e avaliado 15 minutos após o vencimento. O Weave verifica apenas as tabelas que a sua função permite ver; sem a função analyze.table.read, ele não verifica nenhuma tabela, e a primeira linha conta apenas etapas e fluxos de trabalho.

• Tabela não gravada no agendamento. Uma tabela que nenhuma etapa gravou desde que um fluxo de trabalho que a grava venceu no seu agendamento. Uma gravação feita por qualquer etapa conta, inclusive uma em outro fluxo de trabalho ou uma execução que você mesmo iniciou. A constatação mostra o horário da última gravação em vez de há quanto tempo ela ocorreu. Uma execução que falhou conta como não gravada; assim, as tabelas de um fluxo de trabalho agendado com falha são relatadas aqui e também em Falha na última execução.

O Weave relata uma tabela como não verificada, com o motivo, em vez de não gravada, quando:

• um fluxo de trabalho que a grava está em execução, está na fila ou acabou de terminar e os resultados ainda não foram registrados;
• uma etapa que a grava foi ignorada em uma execução desde o vencimento do agendamento, seja pelas próprias condições, seja por não encontrar nada a fazer, como uma importação cujos arquivos não tinham mudado;
• uma etapa que a grava pode ser ignorada sem registro disso: ela está em um fluxo de trabalho padrão com uma condição que salta para outra etapa, ou em um fluxo de trabalho Serial padrão com uma etapa que vai para outra etapa quando falha, ou fica em um contêiner com condições ou em um loop que pode ser executado zero vezes;
• o fluxo de trabalho concluiu uma execução desde o vencimento, mas o registro da etapa de gravação dessa execução está ausente;
• uma etapa em qualquer parte do projeto escolhe a tabela que grava com uma variável cujo valor o Weave não consegue determinar, então ela pode gravar esta tabela;
• o agendamento é executado com frequência menor que a cada 180 dias, que é o limite do histórico de execuções do Weave; ou
• o agendamento de um fluxo de trabalho não é válido, ou o histórico de execuções não pode ser lido.

Uma tabela não é verificada de forma alguma quando:

• não tem limite de atualização (abaixo), e nenhum fluxo de trabalho com um evento agendado próprio habilitado a grava. Um fluxo de trabalho que outro fluxo de trabalho executa, por meio de uma etapa Executar fluxo de trabalho ou Macro, ou como um fluxo de trabalho colocado dentro dele, conta apenas pelo seu próprio agendamento;
• as únicas etapas que a gravam estão desabilitadas, ficam em um contêiner desabilitado ou ficam em um ponto de interrupção ou depois dele; ou
• ela é uma visão.

O segundo desses casos não se aplica dentro de um loop que é executado: um loop executa todas as etapas dentro dele, mesmo uma desabilitada, em um contêiner desabilitado ou em um ponto de interrupção ou depois dele.

Um evento agendado salvo após o seu último vencimento não é avaliado até vencer novamente.

Um fluxo de trabalho cujas execuções levam mais tempo que o intervalo do seu agendamento ignora os disparos que vencem enquanto ele está em execução; assim, entre as execuções, as tabelas dele podem ser relatadas como não gravadas; O evento agendado venceu durante uma execução relata a causa.

Quando a etapa que gravou uma tabela pela última vez é uma à qual você não tem acesso, a constatação diz “uma etapa à qual você não tem acesso” e ainda mostra o horário da gravação. “180 dias” em uma constatação é o limite do histórico de execuções do Weave, não um fato sobre a tabela.

Tabelas com limite de atualização. Um limite de atualização é o número máximo de horas que pode passar entre gravações de uma tabela, de 1 a 4.320 (180 dias). Uma tabela com limite é avaliada com base nele em vez de nos agendamentos dos fluxos de trabalho que a gravam. Isso permite definir um limite mais folgado ou mais rígido do que um agendamento oferece, e verificar uma tabela que nenhum fluxo de trabalho agendado grava. Assim como nos agendamentos, uma tabela conta como gravada quando uma etapa que a grava termina.

• Tabela não gravada dentro do tempo definido. Nenhuma etapa gravou a tabela por mais tempo que o limite dela. A constatação mostra o horário da última gravação e o limite.

O Weave relata uma tabela com limite como não verificada, com o motivo, em vez de não gravada, quando:

• um fluxo de trabalho que a grava está em execução, está na fila ou acabou de terminar e os resultados ainda não foram registrados;
• um fluxo de trabalho que a grava iniciou uma execução depois que o limite passou e a concluiu, mas o registro da etapa de gravação dessa execução está ausente;
• uma etapa em qualquer parte do projeto escolhe a tabela que grava com uma variável cujo valor o Weave não consegue determinar, então ela pode gravar esta tabela;
• nenhuma etapa do projeto a grava, como uma tabela que você carrega manualmente, então o Weave não tem uma gravação a partir da qual medir; ou
• o histórico de execuções não pode ser lido.

Uma etapa ignorada não torna não verificada uma tabela com limite: a tabela continua sem ser gravada por mais tempo que o limite. Uma visão não pode ter limite, e transformar uma tabela em visão remove o limite. Uma cópia de uma tabela, ou uma tabela criada a partir de um dos seus instantâneos, começa sem limite.

Para definir um limite, selecione a tabela na lista Tabelas do projeto e escolha Ver/editar detalhes da tabela. Em Atualização, selecione Warn if this table isn’t written for more than, insira o número de horas e clique em Update. Desmarque a caixa de seleção para remover o limite. Enquanto nenhum limite estiver definido, a caixa indica os fluxos de trabalho agendados com base em cujos agendamentos a tabela é avaliada, ou informa que nenhum fluxo de trabalho que você pode abrir a grava em um agendamento. Atualização não aparece para uma visão nem para uma tabela que você está criando, nem sem a função analyze.workflow.read, e alterá-la requer analyze.table.write.

Você também pode pedir a um assistente de IA conectado pelo PlaidCloud MCP que defina o limite de atualização da tabela (a ferramenta dele é table_upsert, com freshness_max_age_hours), ou chamar a API da plataforma:

PUT /rest/v1/analyze/weave/freshness
{"project_id": "<project>", "table_id": "<table>", "freshness_max_age_hours": 24}

Envie null no lugar do número para removê-lo, e a tabela volta a ser avaliada com base nos agendamentos de quem a grava. GET /rest/v1/analyze/weave/freshness?project_id=<project>&table_id=<table> retorna o limite e scheduled_writers, os fluxos de trabalho agendados com base em cujos agendamentos a tabela é avaliada quando não tem limite. Ler um limite requer as funções analyze.table.read e analyze.workflow.read, e definir um requer analyze.table.write e analyze.workflow.read. Você só pode definir um limite em uma tabela que a sua função permite ver, e não enquanto o projeto estiver bloqueado.

Tabelas que um fluxo de trabalho lê, gravadas desde então. Para um fluxo de trabalho que lê uma tabela gravada por outro fluxo de trabalho, o Weave verifica se nenhum outro fluxo de trabalho gravou na tabela desde a última vez que o fluxo de trabalho a leu. Uma tabela conta como lida ou gravada por uma etapa que a indica como entrada ou saída e que terminou em uma execução. O Weave lê o que o histórico de execuções registra, não os dados da tabela.

• Lê uma tabela gravada desde a última leitura. Um fluxo de trabalho leu uma tabela pela última vez em uma das suas execuções, e um fluxo de trabalho diferente gravou nessa tabela desde então, então os resultados dele podem estar desatualizados. A constatação indica a execução que leu a tabela pela última vez e os fluxos de trabalho que gravaram nela. Um fluxo de trabalho com um evento agendado habilitado, ou executado por outro fluxo de trabalho que tenha um, só é relatado depois que um agendamento que o executa vencer após a gravação; um fluxo de trabalho que nada executa em um agendamento é relatado imediatamente.

Estes casos não contam como gravação desde então:

• uma gravação feita pelo próprio fluxo de trabalho, inclusive uma feita durante a sua execução por um fluxo de trabalho que ele executa por meio de uma etapa Fluxo de trabalho: Executar, Fluxo de trabalho: Loop ou Fluxo de trabalho: Execução condicional;
• uma tabela que o fluxo de trabalho grava em uma execução antes que qualquer etapa dessa execução a leia, como uma tabela de preparação, a menos que a gravação tenha sido feita por uma etapa Tabela: Anexar ou Tabela: Upsert, ou por uma etapa Tabela: Exclusão no local com filtro, que mantêm as outras linhas da tabela; e
• uma gravação feita antes de a etapa que a fez ter sido salva pela última vez, já que a etapa pode ter gravado em uma tabela diferente naquela época.

O Weave relata o fluxo de trabalho como não verificado, com o motivo, em vez de desatualizado, quando:

• ele está em execução, ou acabou de terminar e os resultados ainda não foram registrados;
• uma etapa que lê a tabela foi ignorada em uma execução posterior à gravação;
• o agendamento que o executa não é válido;
• nenhuma das execuções recentes dele terminou de ler a tabela, enquanto outro fluxo de trabalho gravou nela ou pode ter gravado;
• uma etapa que lê a tabela foi salva desde o início da última execução bem-sucedida, então o Weave não consegue saber se essa execução a leu. Qualquer salvamento conta, mesmo um que não altere nada do que a etapa lê;
• uma das etapas dele lê tabelas que o Weave não consegue determinar a partir das configurações da etapa, como uma etapa IA: Etapa de LLM, uma etapa Report, uma etapa Execução: Python remoto ou uma etapa que lê várias tabelas e encontra uma delas por pesquisa, como uma etapa Tabela: União distinta ou Tabela: União total pode fazer; escolhe uma tabela com uma variável; indica uma tabela por um nome que mais de uma tabela tem; lê uma visão; ou lê uma tabela de outro projeto;
• uma tabela que ele lê também é gravada por uma macro, cujas execuções o Weave não vê, ou por uma etapa de outro fluxo de trabalho que foi executada desde então e escolhe a tabela que grava com uma variável, a indica por um nome que mais de uma tabela tem, ou grava tabelas que o Weave não consegue determinar; ou
• o histórico de execuções dele não pode ser lido.

Um fluxo de trabalho sem execuções nos últimos 30 dias não é verificado dessa forma.

O que esta verificação não vê:

• leituras e gravações mais antigas que o histórico de execuções que o Weave lê, que corresponde aos últimos 30 dias e, para cada fluxo de trabalho, às suas últimas 20 execuções;
• a condição de uma etapa que verifica uma tabela, o que não conta como leitura dela;
• uma gravação de outro fluxo de trabalho em uma tabela à qual o fluxo de trabalho adiciona linhas e depois lê na mesma execução, a menos que ele as adicione com uma etapa Tabela: Anexar ou Tabela: Upsert;
• uma leitura anterior feita por uma etapa quando outra etapa do fluxo de trabalho leu a mesma tabela mais recentemente;
• uma gravação dentro de uma macro feita por uma etapa que escolhe a tabela com uma variável ou grava tabelas que o Weave não consegue determinar; e
• gravações feitas antes de a etapa de gravação ter sido salva pela última vez, mesmo quando o salvamento não alterou nada do que ela grava, até que o fluxo de trabalho dela seja executado novamente.

Sem a função analyze.table.read, nenhum fluxo de trabalho é verificado dessa forma. Quando um fluxo de trabalho ou uma tabela que gravou ou foi lida é um ao qual você não tem acesso, a constatação diz “um fluxo de trabalho ao qual você não tem acesso” ou “uma tabela à qual você não tem acesso”, sem dizer quantos.

Uma etapa de um tipo para o qual o Weave não tem regra é relatada como não coberta, não como sem problemas.

Tabelas que dependem de uma execução com falha. Quando a última execução de um fluxo de trabalho falhou antes que uma etapa que grava uma tabela terminasse, essa tabela ainda contém os dados anteriores, ou apenas parte dos novos dados. O Weave acompanha a tabela pelas etapas que a leem e pelas tabelas que elas gravam, em todos os fluxos de trabalho do projeto, e relata o que depende dela:

• Lê uma tabela que uma execução com falha não terminou. Um fluxo de trabalho lê a tabela, ou uma tabela construída a partir dela, não importa quantas etapas depois. A constatação indica a tabela que ele lê, a tabela que a execução com falha não terminou e o fluxo de trabalho que falhou, com o horário de início dessa execução.
• Mostra uma tabela que uma execução com falha não terminou. Um painel tem um gráfico sobre uma tabela publicada que é essa tabela, ou foi construída a partir dela, ou sobre um conjunto de dados SQL que lê uma tabela assim. O Weave lê a lógica de template de um conjunto de dados SQL com as tags removidas, então uma tabela em um ramo que nunca é seguido pode contar. A constatação é sobre o painel e é listada na guia Weave de cada projeto cujas tabelas os gráficos dele mostram.

O Weave notou o painel “Board Pack”: ele mostra a tabela “Margin”, construída a partir da tabela “Sales”, que o fluxo de trabalho “Import Sales” não terminou de gravar na sua última execução, em 27 Oct 09:15 UTC, então os gráficos dele podem mostrar dados antigos ou incompletos

Cada fluxo de trabalho com falha é uma constatação própria, e ela desaparece quando a última execução desse fluxo de trabalho deixa de falhar. O fluxo de trabalho que falhou não é avisado aqui sobre a sua própria execução; a constatação Falha na última execução dele cobre isso.

Estes casos não contam como uma tabela que a execução com falha não terminou:

• uma tabela cuja etapa foi ignorada de propósito, como uma etapa cuja condição não foi atendida, uma etapa desabilitada ou uma importação que ignorou um arquivo já carregado;
• uma tabela cuja etapa uma execução pode pular. Em um fluxo de trabalho que não é avançado, o desvio de uma condição, ou o desvio de uma etapa com falha em um fluxo de trabalho serial, abrange todas as etapas. Em um fluxo de trabalho avançado, abrange uma etapa dentro ou depois de um contêiner de execução que verifica condições, e uma etapa em um loop;
• uma tabela que outro fluxo de trabalho substituiu por completo depois do início da execução com falha, em vez de adicionar linhas a ela; e
• para um fluxo de trabalho, uma tabela que ele mesmo substituiu antes de lê-la, na sua última execução que a leu.

Um fluxo de trabalho em execução não é avaliado até que a execução termine. Quando o histórico de execuções não pode ser lido, o Weave relata esses casos como não verificados em vez de sem problemas.

O que esta verificação não vê:

• uma execução que terminou sem que nenhuma etapa registrasse uma falha, como uma cujo servidor parou, e uma execução que alguém interrompeu;
• uma tabela que uma etapa escolhe com uma variável, indica por um nome que mais de uma tabela tem, lê por meio de uma visão ou lê de outro projeto;
• um gráfico de painel sobre uma consulta salva, ou sobre um conjunto de dados SQL cujo SQL o Weave não consegue ler depois que a lógica de template é removida;
• uma tabela cujo nome é montado por um template;
• uma tabela que um conjunto de dados SQL indica sem um esquema, a menos que o esquema do próprio conjunto de dados seja o esquema de relatórios do projeto;
• qualquer conjunto de dados SQL em um projeto em um data warehouse Snowflake ou Databricks;
• uma tabela que não está publicada, e aplicativos Panel; e
• execuções mais antigas que o histórico de execuções que o Weave lê, que corresponde aos últimos 30 dias e, para cada fluxo de trabalho, às suas últimas 20 execuções.

Você vê a constatação de um painel apenas para um painel que pode abrir. Sem a função analyze.table.read, nenhuma das duas verificações é executada.

Totais de métricas incomuns. Todos os dias, o Weave lê as métricas do seu projeto e relata uma cujo período concluído mais recente ficou muito fora do habitual, indicando o item, como um cliente ou uma fábrica, por trás da mudança. Consulte Totais de métricas incomuns.

Revisando um fluxo de trabalho

Uma revisão verifica um fluxo de trabalho antes que você confie nele. Ela executa as verificações do Weave no fluxo de trabalho e nas suas etapas, incluindo as etapas de qualquer fluxo de trabalho que ele executa, e mais três que o Weave só executa em uma revisão, porque leem mais do que a guia Weave pode se dar ao luxo de ler toda vez que é aberta:

• Uma alocação que alimenta as próprias entradas. Para cada etapa de alocação que o fluxo de trabalho executa, se o que ela grava retorna — por quaisquer etapas, em qualquer fluxo de trabalho — para a tabela que ela aloca ou para a tabela de direcionadores dela. Quando isso acontece, quanto a etapa aloca, ou como distribui o valor, depende do que ela alocou em uma execução anterior. O Weave indica as etapas pelas quais o loop passa e pede que você verifique se o loop é intencional. Um loop que não passa por nenhuma etapa de alocação, como uma carga incremental que lê a tabela à qual anexa linhas, não é relatado.
• Tabelas e colunas de direcionadores de alocação. Se a tabela de direcionadores que uma etapa de alocação usa existe e tem todas as colunas que a etapa lê dela. Uma coluna de direcionador que a etapa preenche com uma constante ou uma expressão não é procurada. Uma tabela de direcionadores construída em qualquer outro lugar é verificada como está agora; quando uma etapa deste fluxo de trabalho a constrói, as colunas dela não são conhecidas até essa etapa ser executada, então o Weave relata a alocação como não verificada em vez de aprovada. Ele também relata a alocação como não verificada quando a etapa escolhe a tabela de direcionadores com uma variável ou um caminho de pasta, quando o fluxo de trabalho é uma macro e quando a sua função não consegue ver a tabela.
• Segurança em nível de linha em uma coluna renomeada. Para cada tabela que o fluxo de trabalho grava, se ela tem uma coluna marcada com a dimensão que um atributo de segurança em nível de linha usa, mas que não tem o nome desse atributo. A segurança em nível de linha filtra apenas colunas com o nome dos seus atributos, então não filtra essa coluna. Esta verificação requer a função Arquiteto no projeto; para qualquer outra pessoa, a revisão diz que ela não foi verificada, e o mesmo vale para uma tabela que o fluxo de trabalho indica com uma variável ou um caminho de pasta.

Uma revisão começa dizendo o que encontrou e em quanto do fluxo de trabalho, e nunca termina com um atestado de que está tudo bem:

Weave found 2 problems in the workflow "Q3 Close". It couldn't finish checking 1
of its 8 steps (listed below), so it may have missed problems in those. See below
for what these checks don't cover.

Weave noticed the step "Allocate rent": it uses the column "sq_ft" from its driver
table "Floor space", which doesn't have that column. Pick a column the table has,
or add "sq_ft" to it.
Weave noticed the step "Allocate IT cost": its output flows back into its driver
table "IT driver" through "Build IT driver", so how it spreads what it allocates
depends on what it allocated on an earlier run. Check whether that loop is
intended.
Weave hasn't checked the step "Allocate IT cost" — whether its driver table
"IT driver" has the columns it uses: the step "Build IT driver" builds that
table, so its columns aren't known until that step runs.

As etapas que a sua função não consegue ver contam no total, e a revisão diz que não as verificou.

Uma revisão lista o que ela não verifica. Ela não executa as verificações do Weave sobre tabelas — se uma tabela gravada em um agendamento está atrasada e se uma tabela que o fluxo de trabalho lê foi gravada desde então —, que leem o projeto inteiro e são executadas na guia Weave. Para um fluxo de trabalho com etapas de alocação, ela não verifica se cada valor a ser alocado encontra uma linha de direcionador ou um membro de dimensão correspondente, se as tabelas de origem e de direcionadores contêm valores no mesmo nível de detalhe, nem loops que passam por uma etapa que indica a sua tabela dentro de SQL ou com uma variável.

Para revisar um fluxo de trabalho, abra-o na tela ou na grade Etapas e escolha Verificar. O botão está disponível para quem pode editar o fluxo de trabalho e ler as tabelas do projeto. A janela Verificação do Weave mostra, nesta ordem:

• as linhas de abertura da revisão;
• Resumo (escrito por IA), quando a revisão tem um resumo;
• os Problemas da revisão e, depois, o que está em Não foi possível verificar. Um problema que o resumo aponta é marcado com No resumo, e Ir para, ao lado da constatação de uma etapa, seleciona essa etapa onde você escolheu Verificar;
• O que esta verificação não cobre, sempre por último.

Escolher Verificar novamente executa uma nova revisão na mesma janela.

Você também pode pedir a um assistente de IA conectado pelo PlaidCloud MCP que revise um fluxo de trabalho — a ferramenta dele é workflow_review — ou chamar a API da plataforma. Uma revisão requer acesso de leitura às etapas, aos fluxos de trabalho e às tabelas do projeto. As três verificações acima não aparecem na guia Weave; o Weave só as executa em uma revisão.

Na janela Verificação do Weave e pela API da plataforma, uma revisão que encontra problemas também traz um resumo de uma ou duas frases escrito pela IA integrada do PlaidCloud, e até três dos seus problemas para examinar primeiro. A IA vê apenas os problemas da revisão. Antes de o resumo ser retornado, os problemas que ele aponta devem ser da própria revisão, qualquer nome que ele cite e qualquer dígito que ele escreva devem aparecer nesses problemas, e ele não pode usar uma expressão como “nenhum outro problema”. Um resumo que não passa é descartado, e a revisão volta sem ele. Uma revisão sem problemas não tem resumo. Por meio de um assistente de IA, a revisão não tem resumo; o próprio assistente lê as constatações.

Ser avisado quando uma execução termina

Quando a execução de um fluxo de trabalho termina, o Weave examina esse fluxo de trabalho e avisa o responsável por cada problema — consulte Atribuir um responsável a uma constatação — sobre os problemas que mantém contra esse fluxo de trabalho, as execuções dele e a configuração salva das etapas, que ele ainda não leu na guia Weave do projeto, por meio de uma mensagem no aplicativo. Um problema sem responsável, ou cujo responsável não consegue mais vê-lo, vai para a pessoa a quem a execução pertence: quem a iniciou ou, no caso de uma execução agendada, quem salvou o agendamento pela última vez. Cada problema é mencionado uma vez. Enquanto você não o tiver lido na guia Weave, execuções posteriores não o mencionam de novo, então uma etapa Workflow Loop que executa muitos fluxos de trabalho não enche a sua tela de repetições. A contagem no botão Weave o mantém até que você o leia.

A mensagem fica na tela por 30 segundos e tem um link Abrir Weave, que abre a guia Weave do projeto nas constatações sobre o fluxo de trabalho executado. Clique em qualquer outro lugar da mensagem para fechá-la.

Enquanto uma mensagem do Weave sobre um projeto está na tela, uma nova sobre o mesmo projeto se junta a ela em vez de aparecer abaixo. A mensagem mostra a frase mais recente, seguida de uma linha como Mais 2 neste projeto., e fica na tela por 30 segundos a partir da mais recente. Quando as mensagens são sobre fluxos de trabalho diferentes, Abrir Weave abre a guia Weave inteira. Assim, fluxos de trabalho que falham com poucos instantes de diferença geram uma única mensagem em vez de uma para cada. Um lembrete de prontidão sempre aparece sozinho.

Depois que você lê um problema, ele só é mencionado de novo quando o que ele diz muda. Uma constatação de execução descreve a execução de onde veio — a data, o horário, as contagens —, então um fluxo de trabalho que falha toda noite é mencionado de novo na próxima falha depois que você leu a última. Um problema de configuração diz a mesma coisa de uma execução para outra; assim, depois que você o lê, ele não se repete a cada execução.

Uma execução interrompida não envia nada, não importa quem a interrompeu. Um fluxo de trabalho executado por uma etapa Macro Run ou Macro Concurrent não envia nada por conta própria, e essa chamada não é contada entre as execuções dele; um fluxo de trabalho iniciado por uma etapa Executar fluxo de trabalho ou Workflow Loop é uma execução desse fluxo de trabalho como qualquer outra. O que o Weave não conseguiu verificar nunca é enviado dessa forma, nem as constatações sobre tabelas gravadas em um agendamento ou sobre tabelas de um fluxo de trabalho gravadas desde que ele as leu: o Weave avisa sobre essas entre as execuções. Consulte Ser avisado entre execuções.

Ser avisado não é o mesmo que ter lido: um alerta não marca a constatação como lida na guia Weave, nem seguir o link Abrir Weave dele.

Cada problema sobre o qual uma mensagem avisa você é somado à contagem no botão Weave do cabeçalho. Consulte O botão Weave no cabeçalho.

Ser avisado entre execuções

Alguns problemas aparecem sem que nada esteja em execução: uma tabela que não foi gravada no seu agendamento ou dentro do seu limite de atualização; uma execução agendada que não foi iniciada, ou que venceu enquanto o fluxo de trabalho ainda estava em execução; um fluxo de trabalho cujas tabelas outro fluxo de trabalho gravou desde a última vez que ele as leu; e um fluxo de trabalho ou painel que depende de uma tabela que uma execução com falha não terminou. Nenhum fim de execução pode avisar você sobre esses casos, então, uma vez por hora, o Weave verifica cada projeto em busca deles e avisa o responsável por cada problema — consulte Atribuir um responsável a uma constatação — por meio de uma mensagem no aplicativo.

A verificação de hora em hora avisa você sobre cada um desses problemas uma vez, não importa quantas verificações o encontrem, e a primeira verificação de um projeto avisa sobre os que já existem, não importa há quanto tempo. Ela avisa de novo somente depois que o problema desaparece e volta, ou depois que você o leu e o que ele diz mudou, como uma execução agendada posterior que também não foi iniciada. Um problema de agendamento também está entre as verificações do próprio fluxo de trabalho, mas, depois que a verificação de hora em hora avisou você sobre ele, a mensagem ao fim da próxima execução do fluxo de trabalho não o repete até que você o tenha lido — consulte Ser avisado quando uma execução termina. Vários problemas em um projeto chegam em uma única mensagem, que os conta e cita o primeiro:

O Weave notou 3 problemas no projeto “Finance Close”, começando pela tabela “Sales Daily”: a etapa “Load Sales” a gravou pela última vez em 14 Oct 06:00 UTC, e o fluxo de trabalho “Nightly Load” deveria ter sido executado no seu agendamento desde então

Uma tabela que mais de um fluxo de trabalho grava não tem responsável até que alguém atribua um. Quando ela não é gravada no agendamento, o Weave avisa o responsável por cada fluxo de trabalho que deveria tê-la gravado e não gravou. Qualquer outro problema sem responsável não é enviado; ele é listado na guia Weave do projeto.

A verificação é executada como cada responsável, então uma mensagem indica apenas o que a sua função permite ver. Você só é avisado como membro ativo do projeto cuja função permite ver as etapas e os fluxos de trabalho dele, e sobre tabelas apenas se puder ler tabelas.

A mensagem fica na tela por 30 segundos e tem um link Abrir Weave, que abre a guia Weave do projeto, no fluxo de trabalho quando todos os problemas da mensagem são sobre o mesmo. Uma mensagem só é exibida enquanto você está conectado, mas cada problema sobre o qual ela avisa é somado à contagem no botão Weave do cabeçalho, então um que você perdeu continua contado ali. Ser avisado não marca uma constatação como lida.

Marcar uma constatação como lida

Cada constatação tem um id, e você pode marcá-la como lida para que deixe de aparecer como nova — na guia Weave do projeto, clique em Marcar como lida no cartão dela (consulte Marcar constatações como lidas). O id é derivado da própria constatação, então uma constatação que você dispensou volta como nova se o problema subjacente mudar — uma etapa que você marcou como lida depois de corrigir uma coluna reaparece se outra coluna der problema depois.

O estado de leitura é só seu. Marcar uma constatação como lida não a marca como lida para mais ninguém no projeto.

Enquanto um fluxo de trabalho que grava uma tabela atrasada está em execução, o Weave relata a tabela como não verificada. Se você marcar qualquer constatação como lida durante esse período e a execução terminar sem gravar a tabela, a constatação dela volta como nova.

Duas etapas diferentes listadas duas vezes em um fluxo de trabalho são duas constatações, então marcar uma como lida deixa a outra não lida. Um fluxo de trabalho sem nome aparece como “unnamed workflow”, e uma verificação que não pôde ser executada é identificada pelo título, como “Falha na última execução”.

Um resumo de pendências

Um resumo de pendências é o mesmo relatório reduzido ao que você ainda não leu, com a mesma voz. Você pode solicitar um a qualquer momento e pode recebê-lo como uma notificação no aplicativo, com um link Abrir Weave para a guia Weave do projeto.

As constatações que o Weave não conseguiu verificar fazem parte de um resumo de pendências como qualquer outra. Um resumo de pendências que as omitisse discretamente seria exatamente o silêncio tranquilizador que a terceira resposta existe para evitar.