[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

MARCOS STUMPF 14 June 2024, 19:48 Jira Internal Users

@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.

Gabriel DAmore Marciano 14 June 2024, 17:50 Jira Internal Users

@Robson Thanael Poffo @MARCOS STUMPF Deixei os comentários no card e estou encerrando este bug crítico.

Automation for Jira 11 June 2024, 15:51 Jira Internal Users

Link para a thread da mensagem no Slack canal #emergencias:

https://totvsideia.slack.com/archives/C03NT4US9J9/p1718121089081169

Automation for Jira 11 June 2024, 15:51 Jira Internal Users

@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.