Erro Dataflow - App is not installed in customer tenant - Registros não são gravados no datamodel
Description
A partir do dia 21/05/2024 estamos com erros nos jobs dataflow de escrita de dados em datamodels, onde o retorno do job é o abaixo, causando a não escrita no bigquery.
"The app is not installed in customer tenant XPTO. No entity template XYZ information.".
Rastreamos as tenants afetadas e todas elas tem o app instalado e o datamodel presente em sua estrutura. Mesmo assim, reinstalamos o Carol App para verificar se resolveria paliativamente e não surtiu efeito. Segue arquivo de tenants impactadas em anexo.
Dessa forma, é necessário uma verificação do vínculo com o Carol App ou ajuste na pipeline Dataflow.
LOGS GCP
https://cloudlogging.app.goo.gl/t5dP128gfUhCpNRT6
LOG ANALYTICS
https://cloudlogging.app.goo.gl/pRoz5GTYRY8KyW6N6
QUERIES LOG ANALYTICS (a última sumariza tenants, datamodels afetados, datas de incidencia e número de incidencias, fonte do arquivo em anexo).
-- QUERY DADOS DE TENANTS E DATAMODELS POR DATA
-- SELECT
-- DATE(timestamp) AS _date,
-- RIGHT(SPLIT(JSON_VALUE(json_payload.message),'.')[0],32) AS mdmTenantId,
-- SPLIT(SPLIT(JSON_VALUE(json_payload.message),'.')[1],' ')[4] AS mdmEntityType,
-- COUNT(*) AS ERRORS
-- FROM
-- labs-app-mdm-production.global._Default._AllLogs
-- WHERE
-- severity='ERROR'
-- AND STARTS_WITH(JSON_VALUE(json_payload.message), 'The app is not installed in customer tenant')
-- GROUP BY 1, 2, 3
-- ORDER BY 3 DESC
-- QUERY DADOS DE TENANTS POR DATA
-- SELECT
-- DATE(timestamp) AS _date,
-- RIGHT(SPLIT(JSON_VALUE(json_payload.message),'.')[0],32) AS mdmTenantId,
-- COUNT(*) AS ERRORS
-- FROM
-- labs-app-mdm-production.global._Default._AllLogs
-- WHERE
-- severity='ERROR'
-- AND STARTS_WITH(JSON_VALUE(json_payload.message), 'The app is not installed in customer tenant')
-- GROUP BY 1, 2
-- ORDER BY 3 DESC
--QUERY TENANTS DISTINTOS COM ERRO
-- SELECT
-- RIGHT(SPLIT(JSON_VALUE(json_payload.message),'.')[0],32) AS mdmTenantId,
-- COUNT(*) AS ERRORS
-- FROM
-- labs-app-mdm-production.global._Default._AllLogs
-- WHERE
-- severity='ERROR'
-- AND STARTS_WITH(JSON_VALUE(json_payload.message), 'The app is not installed in customer tenant')
-- GROUP BY 1
-- ORDER BY 2 DESC
-- QUERY FINAL ISSUE
SELECT
RIGHT(SPLIT(JSON_VALUE(json_payload.message),'.')[0],32) AS mdmTenantId,
SPLIT(SPLIT(JSON_VALUE(json_payload.message),'.')[1],' ')[4] AS mdmEntityType,
MAX(DATE(timestamp)) AS max_error_date,
MIN(DATE(timestamp)) AS min_error_date,
COUNT(*) AS ERRORS
FROM
labs-app-mdm-production.global._Default._AllLogs
WHERE
severity='ERROR'
AND STARTS_WITH(JSON_VALUE(json_payload.message), 'The app is not installed in customer tenant')
GROUP BY 1, 2
ORDER BY 5 DESCActivity
Details
Priority
Highest
@Breno Zipoli Monteiro Papa ,
@Cindy de Araujo Soares Moore ,
Você acabou de concluir a issue https://jiraproducao.totvs.com.br/browse/IDEIA-129 no Jira Produção e seu comentário anterior foi adicionado como informação de encerramento. Issue TOTVS IDEIA também foi concluída.
#close
Prezado,
Após identificarmos o problema de escrita de dados na tenant unificada, realizamos a correção e agora não temos mais log de erro de escrita.
Peço a gentileza apenas de reprocessarem os datamodels que identificaram o problema, afim de ter toda a massa de dados disponível na plataforma.
Seguimos à disposição.
Boa noite pessoal! Atualizações depois de analisar junto com o :
1. Os erros que estão acontecendo na unificada são devido a queries que não estão utilizando o `--metadata--` ou `---metadata-v2--` . A validação passou pois a temp table que está sendo criada possui os 2 campos que são considerados obrigatórios como "meta campos" : __mdmId & __mdmCounterForEntity que estão de fato na query. Porém, o campo `_mdmTenantId` acaba não sendo criado, o que faz com que a interpretação seja de que aquele registro é pertencente a própria tenant. Nesse caso, não temos um cenário onde a própria unificada é dona do seu registro (pois unificadas recebem registros das tenants customers), e isso ocasiona o erro. A correção que eu fiz (que eu comentei mais acima) resolve a "dor" de ter o erro, mas continuaremos não validando efetivamente que a query não tem nenhum dos `-
metadata` ou `-metadata-v2-` e assumiremos que a dona do dado é a própria tenant (que nesse caso é a unificada) o que, até onde tenho conhecimento, não faz sentido pra negócio. Faria sentido apenas se o processamento estivesse acontecendo na própria customer, onde ela própria é a dona do dado e o valor default do `mdmTenantId` seria ela mesma, mas ainda assim, fica meu questionamento se podemos ter queries sendo executadas sem um dos parâmetros`-metadata` ou `-metadata-v2-` . Vale destacar também que não tendo a informação do `_mdmTenantId` também não é possível fazer o fan-out para os clientes2. O que fica ainda sob investigação (que darei continuidade na segunda-feira) é entender por que as tenants que são do tipo desenvolvimento e que de fato tem o app instalado (o qual elas não são owners) ficaram de fora da validação se o app está instalado ou não
Query que encontramos:
```-- pk: __mdmId
with dmpricesensibilidade as (
select [
struct(0 as pricecodigosensibilidade, \"Não Definido\" as pricedescricaoreduzida),
struct(1 as pricecodigosensibilidade, \"Super Sensível\" as pricedescricaoreduzida),
struct(2 as pricecodigosensibilidade, \"Sensível\" as pricedescricaoreduzida),
struct(3 as pricecodigosensibilidade, \"Não Sensível\" as pricedescricaoreduzida),
struct(4 as pricecodigosensibilidade, \"Não Presente\" as pricedescricaoreduzida),
struct(5 as pricecodigosensibilidade, \"1o Preço\" as pricedescricaoreduzida),
struct(6 as pricecodigosensibilidade, \"Marca Própria\" as pricedescricaoreduzida)
] as sensibilidade
)
select * except(sensibilidade),
left(TRIM(\"2023-03-28T11:03:58.910000-03:00\"),19) as pricetimestamp,
TRIM(CONCAT(pricecodigosensibilidade, ' - ', pricedescricaoreduzida)) as pricecodigoedescricao,
TO_HEX(MD5(CONCAT(pricecodigosensibilidade, pricedescricaoreduzida))) as __mdmId,
0 as __mdmCounterForEntity
from dmpricesensibilidade, unnest (sensibilidade)```
c/c
Mensagem enviada pelo Slack - red-phone - Cindy Soares
Mais alguns esclarecimentos:
• O erro ocorrido com a tenant `da097df17e5d46f7a158d246a0d146bd` foi executando o processamento da unif `935d5554d94b419ab3bed20ec377afd6` app `techfinwinthor` , e de fato essa tenant só tem `winthormaisnegapp` , o erro pra essa tenant ocorreu só no dia 20/05 e depois parou. Essa é uma tenant PRODUCTION
• As outras duas tenants `01192c81bae9434eaacfa9afe7b021a4` e `9b37654efa8645838b28ca99d8e1914d` são `DEVELOPMENT` , e os erros ainda estão ocorrendo desde do dia 20/05. A pergunta é, se unifs deveriam processar dados de tenants Development. Faz sentido?
cc/
Mensagem enviada pelo Slack - red-phone - Cindy Soares
Regression OK para a branch.
• A `qa` soh deve ser mergeada na `master` apos o ser deployado em production + pos deploy (resultados).
Mensagem enviada pelo Slack - plataforma-carol-internal - Douglas Coimbra Lopes
Esta issue foi automaticamente movida para WAITING DEPLOY, pois o PR foi mergeado na branch master no Github.
Github usuário douglascoimbra aprovou um PR e foi adicionado como Shared Assignee nesta issue.
fix: https://totvsideia.atlassian.net/browse/CAPL-5956#icft=CAPL-5956 Correção no processamento de registros de tenants unificadas
Fiz uma busca de quais são as tenants que estão logando o problema e são elas 3 unifs e 4 customers.
```'efc39264c3ee454da66823d6cc047857', – unif
'c33681327c8743e59b3137f58b00a64c', – unif
'0483dfa91ba54cd4b97b1613f1171932' – unif
'9b37654efa8645838b28ca99d8e1914d', – customer apps: totvspricing, totvspricingdev, pricingcosinco
'da097df17e5d46f7a158d246a0d146bd', – customer app: winthormaisnegapp
'01192c81bae9434eaacfa9afe7b021a4', – customer apps: totvspricing, pricingdev
'7194a657aa664aa7b050748410c1b82a', – customer sem apps```
• Para as unifs fiz uma correção e estamos rodando testes de regressão para poder fazer o deploy possivelmente na sexta (31/05).
• Para os customers `9b37654efa8645838b28ca99d8e1914d, da097df17e5d46f7a158d246a0d146bd, 01192c81bae9434eaacfa9afe7b021a4` que tem apps instalados, aind vou analisar cada caso.
• Para o customer `7194a657aa664aa7b050748410c1b82a` sem apps instalado, o log está correto, não há o app instalado, portanto o fanout não será feito.
cc/
Mensagem enviada pelo Slack - red-phone - Cindy Soares
@Breno Zipoli Monteiro Papa ,
@Cindy de Araujo Soares Moore , @Glaucio Scheibel
Comentário enviado para o Jira Produção - https://jiraproducao.totvs.com.br/browse/IDEIA-129:
Iniciamos a trabalhar em sua issue e manteremos você informado!
Atenciosamente,
Equipe TOTVS Inteligência de Dados e IA.
Esta issue foi automaticamente movimentada para QA REVIEW, pois o PR foi aprovado no Github.
Identifiquei 2 cenários que foram afetados pelo deploy do dia 20/05.
• Processamento de registros da própria tenant unificada não estão sendo inseridos no BQ e a mensage de `app não instalado` aparece nos logs
• Processamento com a flag `fanOut=false` (ainda a confirmar)
Mensagem enviada pelo Slack - red-phone - Cindy Soares
@Breno Zipoli Monteiro Papa ,
@Robson Thanael Poffo ,
@Geny Isam Hamud Herrera ,
Esta issue foi planejada para ser entregue até 2024-06-03. Você pode confirmar consultando o campo Due Date desta issue.
Datas já planejadas para esta issue: 2024-06-03
Se o campo External Issue Link estiver preenchido com o link de uma issue válida no Jira Produção o cliente também será notificado no Jira Produção.
Link para a thread da mensagem no Slack canal #red-phone:
https://totvsideia.slack.com/archives/C03NT4US9J9/p1716918527844629