Dados persistidos em staging (CDS e BQ) divergem do recebido em intake
Description
PRDE - Bug default text according to the team DoR (Definition of Ready)
01 - PERSON OF CONTACT (PERSON THAT CAN ANSWER QUESTIONS ABOUT THE PROBLEM):
@Danilo Queiroz Mota
02 - PROBLEM (WHAT'S THE ISSUE?):
Cliente reportou que dados em staging divergem do enviado pelo ERP.
SELECT timestamp_micros(mdmcounterforentity) as mdmcounterforentity, mdmauditId, DELETED
FROM
`carol-985685f68ade47639304.985685f68ade476393049bec85e841da.stg_protheus_carol_se2`
WHERE protheus_pk = '01|0101|04|44558||NF|004228|01'
order by mdmcounterforentity
Dados em CDS também encontram-se divergentes.
SELECT timestamp_micros(mdmcounterforentity) as mdmcounterforentity, mdmauditId, DELETED
FROM
`labs-app-mdm-production.985685f68ade476393049bec85e841da.ext_protheus_carol_se2`
WHERE protheus_pk = '01|0101|04|44558||NF|004228|01'
order by mdmcounterforentity
CREATE OR REPLACE EXTERNAL TABLE `labs-app-mdm-production.985685f68ade476393049bec85e841da.ext_protheus_carol_se2`
OPTIONS (
uris = ['gs://prod-mdm-1-carol-internal-985685f68ade476393049bec85e841da/staging-output/parquet/9291250517d24616b2745fd84e147dcb_se2/*.parquet'],
format = 'PARQUET'
);
Dados na auditoria refletem o que foi enviado pelo ERP.
SELECT timestamp_micros(CAST(counterForEntity AS INT64)) AS mdmcounterForEntity, auditId as mdmauditId, JSON_VALUE(record, '$.DELETED') AS DELETED,
FROM (
SELECT message_id AS messageId, auditId, tenantId, connectorId, stagingType, TIMESTAMP_TRUNC(publish_time, SECOND) AS record_timestamp,
json_value(attributes, '$.counterForEntity') as counterForEntity,
record,
FROM `labs-app-mdm-production.intake.records_landing` l
CROSS JOIN UNNEST(JSON_EXTRACT_ARRAY(payload, '$')) AS record
WHERE DATE(publish_time) = '2023-12-08'
AND tenantId IN (
"985685f68ade476393049bec85e841da"
)
AND stagingType = "se2"
)
WHERE TRIM(JSON_VALUE(record, '$.protheus_pk')) = '01|0101|04|44558||NF|004228|01'
order by counterForEntity
03 - STEPS TO REPRODUCE (STEP (1...N), VIDEO, SCREENSHOTS, LOGS FOLDER, HEARTBEAT, ETC. – IF IS NOT POSSIBLE TO REPRODUCE EXPLAIN THE REASON):
04 - LINKS (ADD A LINK TO THE BUG OR TO THE TENANT):
05 - EXPECTED BEHAVIOR (LIST THE EXPECTED BEHAVIORS TO CONSIDER THIS BUG AS DONE):
Activity
Show:
@Robson Thanael Poffo Efetuei o vinculo entre e para ficar amarrado.
O KT sobre a validação final com o time DE está agendado para amanhã (1/fev).
Sobre o outro card mencionado pela Cindy (
PRDE-3210
) eu atrelei ele ao PX-03 que trata da observabilidade em geral.@Cindy de Araujo Soares Moore , obrigado pelo retorno.
Pelo fato de estar inicialmente ligado à mudança de schema, vamos associar a solução do tema inicial com a issue
A issue aplica uma nova forma que evita eliminação de atributos, evitando parte da mudança de schema em instalações de Carol App.
O @MARCOS STUMPF está acelerando as validações finais do tema.
Este tema está sendo aguardado através da issue:
cc @Danilo Queiroz Mota
@Robson Thanael Poffo
Não conseguimos reproduzir esse cenário em ambiente de teste e analisando o código não encontramos o que poderia ter causado esse problema dos cases do nome da coluna. Mas concluímos que o problema foi causado pela mudança de schema no mesmo momento do envio do dado.
Vamos encerrar esse ticket com as evidências da mudança de schema já compartilhadas aqui anteriormente. Também reforço que os tickets abaixo vão ajudar a evitar o cenário que vimos aqui:
cc/ @Geny Isam Hamud Herrera @Gabriel DAmore Marciano
@Robson Thanael Poffo ,
@Geny Isam Hamud Herrera , @Reinaldo Oliveira Machado Junior , @Cindy de Araujo Soares Moore
This issue was planned to be delivered until 2024-01-22. You can check that by consulting the issue in the Due Date field.
Dates already planned for this issue: 2024-01-22, 2024-01-02
If External Issue Link field is filled, customer was also informed on JIRA TOTVS.
Eu criei um ticket para avaliação que pode ser interessante para investigações futuras: .
@Robson Thanael Poffo ainda um mistério. Pra mim tinha sido a alteração de caixa baixa pra caixa alta que supostamente não tinha ido. Mas não temos evidências disso. Fiz uns testes em sandbox e vi comportamentos diferentes a cada momento que repetia o teste. Suspeitava de algum problema no update de staging schema relacionado a isso. Mas eu analisei todo o código de update desse schema e não encontrei algo que deixasse atualizar a coluna pra caixa alta.
E sim, pro caso das outras colunas o outro ticket resolve. Minha preocupação é com as atualizações de caixa baixa e caixa alta.
Mas as outras colunas terem entrado como null comprova que o update da instalação tinha executado, antes do Dataflow processar o dado, o que sugere que a coluna DELETED não estava como esperando.
A partir de amanhã eu estou de férias, e o @Reinaldo Oliveira Machado Junior vai fazer novos testes pra esse cenário. No comentário anterior tentei agrupar o máximo de informação que consegui.
@Cindy de Araujo Soares Moore , entendi que as colunas E2_XE4COD, E2_XE4TIPO, and E2_XE4COND foram removidas e adicionadas na sequencia. E entendo ter perdido os dados por conta desta operação. Entendo que esse cenario é coberto na issue , certo?
Por qual motivo o valor de DELETED foi perdido?
There are some highlights to share about this case:
There are other column values in the record missing: DELETED, E2_XE4COD, E2_XE4TIPO, and E2_XE4COND are null.
The Carol app installation was triggered right before the record was sent. The staging tables were updated too close to the intake call sending the record:
Schema change notification triggered by Carol app installation removed three columns from the schema E2_XE4COD, E2_XE4TIPO, and E2_XE4COND:
Schema change notification triggered by flexible schema flag added the three columns back:
Checking the differences between the app versions, 1.2.5 and 1.2.6, I noticed a change in the case of the column name, it was changed from
deleted
toDELETED
. The staging Dataflow process could not recognize the column depending on the case the record is sent and the column name in the staging table.snapshot.json v1.2.5: https://console.cloud.google.com/storage/browser/_details/prod-mdm-1-carol-apps/prod/painelprotheusapp/1.2.5/snapshot.json;tab=live_object?authuser=1&project=labs-app-mdm-production
snapshot.json v1.2.6: https://console.cloud.google.com/storage/browser/_details/prod-mdm-1-carol-apps/prod/painelprotheusapp/1.2.6/snapshot.json;tab=live_object?authuser=1&project=labs-app-mdm-production
Discussion about these findings:
The BigQuery tables never change the column name case, unless the table is recreated (new provision is a case):
Testing app installation in sandbox the staging schema column wasn’t updated to
DELETED
in v1.2.6:The endpoint to test sending the data to intake (record from landing table)
1
2
3
4
5
6
Query returning the records in production:
1
2
3
4
5
Query getting landing records:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
cc/ @Geny Isam Hamud Herrera @Reinaldo Oliveira Machado Junior
@Robson Thanael Poffo ,
@Geny Isam Hamud Herrera ,
This issue was planned to be delivered until 2024-01-02. You can check that by consulting the issue in the Due Date field.
Dates already planned for this issue: 2024-01-02
If External Issue Link field is filled, customer was also informed on JIRA TOTVS.
Message thread link on #red-phone channel:
https://totvscarol.slack.com/archives/C03NT4US9J9/p1702408172329549