[Observabilidade] As contagens não estão batendo entre o CarolPipelinesExecutionSummary e os CarolDataModelSubscriptionSent
Description
O time do Smartlink trouxe esta visão na mensagem onde a quantidade de registros recebidos pelo CarolDataModelSubscriptionSent não bate com o que foi enviado no CarolPipelinesExecutionSummary
Resultados
11/06/24
- O card em si não é um bug da plataforma, mas sim um comportamento esperado quando temos processamento de dados que eventualmente podem processar o mesmo batch.
As contagens não estão batendo pois o controle de processamento é diferente do envio de dados para as subscriptions. Para entender com mais detalhes, criei este diagrama (aba Concorrência no evento de Subscription)
- Agora, está sendo avaliada uma forma de conseguirmos enviar novamente o evento de CarolPipelinesExecutionSummary quando os batches são processados novamente por uma pipeline que foi gatilhada por outro batch.
14/06/24
- Depois de conversarmos com o time do Smartlink na tarde de ontem, juntamente com o Robson e Teixeira, chegou-se a conclusão de que esse comportamento merece uma revisão de negócio com mais calma tanto do lado do Smartlink, onde eles irão desenhar o fluxo que eles julgam ideal, quanto do lado da Carol o time irá avaliar se a demanda do time do Smartlink faz sentido perante a necessidade apresentada.
- Para a meta de H1/24, a deduplicação pelo mdmId atende o requisito apresentado. O time do Smartlink está fazendo as adequações para voltarmos com os testes integrados.
- Quanto a avaliação de enviarmos novamente o evento de CarolPipelinesExecutionSummary, foi iniciada uma prova de conceito nesta branch onde, de forma resumida:
- Um novo evento chamado CarolPipelineExecutedCollateralBatch é criado toda vez que um batch que já foi finalizado é reprocessado por um outro batch que está em processamento.
- No evento final do processamento, o CarolPipelinesExecutionSummary irá considerar a deduplicação de todos os batches processados.
- O que é importante ressaltar é que essa branch está recebendo um “hard stop" em seu desenvolvimento hoje, devido ao que foi citado anteriormente, onde o time do Smartlink irá reavaliar o que eles precisam de demanda, antes de sairmos implementando novas funcionalidades.
- Foi criado um documento no notion onde contém links para:
- Modelo de ER do processamento batch
- Vídeo do @Gabriel DAmore Marciano explicando todo o problema trazido pelo time do Smartlink e como a investigação foi feita, servindo como material de apoio de de KT para os demais.
- Vídeo do @Gabriel DAmore Marciano com uma POC com uma possível solução do problema trazido pelo time do Smartlink
Activity
Show:
@Gabriel DAmore Marciano Ok entendi o cenário, acabo de assistir o KT, mas fiquei com uma dúvida, se o batch B acionou o
pipeline_process
que processou novamente os registros enviados dentro da janela de tempo do batch A, o que o batch B enviou de dados novos?Fiquei com a impressão de que o batch B não enviou dados para processar ou enviou os mesmos dados, que com a deduplicação, não alterou a quantidade apresentada no CarolPipelinesExecutionSummary.
@Robson Thanael Poffo @MARCOS STUMPF Deixei os comentários no card e estou encerrando este bug crítico.
Link para a thread da mensagem no Slack canal #emergencias:
https://totvsideia.slack.com/archives/C03NT4US9J9/p1718121089081169
@Gabriel DAmore Marciano ,
Esta issue foi planejada para ser entregue até 2024-07-05. Você pode confirmar consultando o campo Due Date desta issue.
Datas já planejadas para esta issue: 2024-07-05
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.