okay, obrigado.

@Robson Thanael Poffo

Conforme alinhamos, vamos seguir com as seguintes tratativas no card:

• Remover a necessidade que o fluxo de resiliência de execução da task necessita ir buscar a task do banco Postgres toda vez e passar a utilizar o que já está em memória (somente para esta task).

• No job DeleteTenantDependenciesJob adicionar uma validação para que uma nova task DELETE_TENANT não seja criada em caso onde já existir uma task em andamento para a tenant em questão (READY/RUNNING). Dessa forma iremos evitar múltiplas tasks de deleção de tenants para uma mesma tenant (elas ficam travadas em READY até que a task que está em execução termine, depois elas ficam em um loop de falha na busca pela tenant dentro do processo de execução da task de deleção de tenant - devido a tenant já ter sido excluída no PG).

• Na classe de execução da task DELETE_TENANT (DeleteTenantTaskProcessor) adicionar um tratamento de exceção caso a tenant em questão não exista mais, e, quando isso ocorrer, devemos falhar a task (porque ela deve ter sido criada erroneamente pelo job DeleteTenantDependenciesJob).

@Renan Fernando Schroeder , vamos avaliar se vale um controle para cancelar a task caso a tenant não exista, cenário causado pelo início de tasks de DELETE TENANT de forma concorrente. Com isso vamos evitar tasks em loop / falhando constantemente.

@Robson Thanael Poffo

Durante a implementação do card CAPL-6401, aprofundamos bastante o tema e entendemos que o que levou a task a falhar de fato não foi o fato da colisão com o snapshot da tenant no ES. O exception que aparece no card é um erro que ocorre nestes casos, mas a plataforma em si já se encarrega de tentar executar a própria task novamente momentos depois. Tanto que esta falha não é registrada nos task logs, apenas nos logs. A única falha que foi registrada no task log e que de fato parece ter sido a última, e que levou a task a falhar, sendo uma inconsistência na busca pelo id da task no banco Postgres no dia 30/07 (Task d63834a50d4d4bdcbcabbc89d2f2ad4 not found).

O que entendemos que vale mais a pena corrigir é remover a necessidade que o fluxo de resiliência de execução da task necessita ir buscar a task do banco Postgres toda vez e passar a utilizar o que já está em memória (somente para esta task).

Como não temos mais os registros de logs do caso reportado pelo card entre dia 23 e 30/07, não temos condições de entender melhor o que ocorreu para que a task ficasse tantos dias em execução. Mas entendemos que a melhoria que adotamos irá melhor a resiliência do reprocessamento de deleção de tenants, garantindo que a task irá continuar a ser reprocessada em casos de colisão com snapshot do ES. Se acaso alguma task de deleção de tenant volte a colidir com alguma inconsistência do ES, ela será reprocessada mais vezes do que o normal, e assim podemos priorizar a investigação olhando mais a fundo os logs para entender quais outras melhorias poderemos adotar no fluxo para garantir maior agilidade no processamento da task.

De acordo com o plano?

@Robson Thanael Poffo ,
@Renan Fernando Schroeder , @Rodrigo Bechtold ,

Este issue foi planejada para ser entregue até 2024-09-13. Você pode confirmar consultando o campo Due Date desta issue.

Data já planejadas para esta issue: 2024-09-13

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.