Tasks stuck em running

Description

Problema


Após o deploy para o novo manifesto detectamos tasks em running por um período acima do normal, gerando efeitos colaterais de tasks não processadas pela validação de enfileiramento de tasks.

Na sexta-feira (26/07), efetuamos o cancelamento de 2,334 tasks descrito nessa thread do slack: https://totvsideia.slack.com/archives/C03LA7B048G/p1722001624507159
Na data de hoje (29/07) efetuamos o cancelamento de 19 tasks conforme descrito nessa thread: https://totvsideia.slack.com/archives/C03LA7B048G/p1722264887231689

Efetuamos a avaliação das seguintes tasks:

https://dpadua.carol.ai/dpadua/carol-ui/tasks/activity/3e3e970d-2469-4a2f-99b3-a076bc3438ba?p=1&ps=25&sort=dateUpdated&order=DESC&filters=%5B%7B%22term%22:%22%22%7D,%7B%22dateUpdated%22:%5B%22after%22,%222024-07-28T15:44:21.172Z%22%5D%7D,%7B%22hideInternal%22:%22false%22%7D,%7B%22taskId%22:%5B%223e3e970d24694a2f99b3a076bc3438ba%22%5D%7D%5D

image-20240729-155155.png

https://tecnotextil.carol.ai/tecnotextil/carol-ui/tasks/activity/f453a24c-6331-44f2-85b8-0a8881e14045?p=1&ps=25&sort=dateUpdated&order=DESC&filters=%5B%7B%22dateUpdated%22:%5B%22after%22,%222024-07-28T15:47:35.876Z%22%5D%7D,%7B%22hideInternal%22:%22false%22%7D,%7B%22taskId%22:%5B%22f453a24c633144f285b80a8881e14045%22%5D%7D%5D

image-20240729-155213.png

https://ldcelulose.carol.ai/ldcelulose/carol-ui/tasks/activity/4eac3500-2812-4e1c-9ef4-80c9b4415d3b?p=1&ps=25&sort=dateUpdated&order=DESC&filters=%5B%7B%22dateUpdated%22:%5B%22after%22,%222024-07-28T15:48:01.119Z%22%5D%7D,%7B%22hideInternal%22:%22false%22%7D,%7B%22taskId%22:%5B%224eac350028124e1c9ef480c9b4415d3b%22%5D%7D%5D

image-20240729-155232.png

Temos 19 casos detectados na thread de hoje (29/07).

Objetivo


Caso as tasks fiquem stuck, elas devem ser canceladas pelo processo de stale.

Ideal entender o que alterou nesse processo para gerar esses casos.


Findings

Análise de causa:

  1. Hibernate não estava conseguindo ler algumas tasks do postgres pois continham excesso de dados na coluna JSONB secure_data;
  2. Logs do erro não estavam sendo produzidos, pois os dados faziam parte do payload, e portanto estava truncando a mensagem. @Henrique Cavarsan Barbosa encontrou os logs truncados;
  3. As tasks em questão apresentaram esse volume dados anômalo em decorrência do bug CAPL-6435, do deploy da última quinta-feira, onde foi processada uma janela de dados 60 mil vezes maior que a correta. Tasks do tipo CONSOLIDATE_CDS_DATA salvam uma lista de parquets que, neste caso, foi excessiva.

Estas tasks de CONSOLIDATE_CDS_DATA são provenientes de um processo gerenciado pelo @Bruno Tortato Furtado, que, em conversa com o Henrique, optaram por cancelar o processamento. Isto resolveu o problema imediato.

IDs das tasks removidas

7cb19b2c-e454-4b0b-8513-29f94d8418d9
1cb4d710-a7e0-41db-abc6-20ca91629754
84a02c8c-749a-4641-a578-3b1264cf5bbd
43c97198-2dd9-454d-b17c-407a04d79805
2211772b-bb0b-4e46-a091-ff580d06a61c
bdffe64e-dffd-4bfc-a017-6e10fb90b944
1bc628e8-5423-47f1-8d21-d17aa07e5267
3df07b5f-7700-4d59-b7bb-469453a458fe
9e91f23b-18f9-4d1c-89d6-c1eab2d57357
ad45f28b-3fa0-4de5-8b13-30216e4fd69a
97e0df8f-d542-421c-80bf-5eb73f38ff1f
30576dbd-4204-4a8e-a1e7-9dbe2e5a5521
c6a0ca9a-f5c4-4982-a130-e1295cecae5a
26bda9a3-ad01-40bb-ac78-045ea0cea50e
2ec9dfbc-10df-4e28-8923-3135b94e4d8e
5da5d0d2-8549-44d7-813c-14b48a101bbd
6d13e6e6-31ab-47ce-9006-b22265213258
3d94aa9f-79bf-4845-8e4a-65e57b0831e1
60e191a9-3f4d-4223-9873-36088acf964d
7269bc7d-a092-4944-88e0-8537122e135c
e8986076-7940-44cb-8559-3d254071300e
b721d069-4910-4cca-b439-a83939eee0ca
08311fb5-2926-4454-a876-5a6eefd07977
35282a53-7ddc-4ba8-989d-3ed483f895d7
ead39da3-2281-49db-bc9e-47aad1a7a6de
6846299b-e5a0-4806-bc91-2cee956cc6ea
129c81d4-95e3-45af-b545-90eed666660d
39190055-e299-44d9-b83d-f939ca0747d7
373036da-45cb-4aa7-8f31-f72dd5018191
c4b9cfac-81ec-4101-858a-2ba80ac55108

A execução do stale check foi normalizada após cancelamento das tasks.

Follow ups

Identificamos 2 problemas que contribuíram ou agravaram para este cenário:

  1. Precisamos adicionar um limite de payload para os logs (do lado produtor, logger), de tal forma que não perdemos as mensagens de erro (apenas parte do conteúdo) conforme ocorreu neste incidente;
  2. Precisamos implementar a produção de métricas, do lado do backend, que permitam monitorar o StaleTaskCheckJob, e assim alertados quando ele não estiver funcionando e quando tarefas estiverem sendo reprocessadas repetidamente (dias);

Activity

Automation for Jira 30 July 2024, 21:06 Jira Internal Users

@Robson Thanael Poffo ,
@Lucas Noetzold ,

Esta issue acabou de ser vinculada na(s) issue(s) https://totvsideia.atlassian.net/browse/CAPL-6385#icft=CAPL-6385,https://totvsideia.atlassian.net/browse/PRDE-4170#icft=PRDE-4170,https://totvsideia.atlassian.net/browse/PRDE-4171#icft=PRDE-4171, conforme menções feitas no campo description.

Automation for Jira 30 July 2024, 20:28 Jira Internal Users

@Robson Thanael Poffo ,
@Lucas Noetzold ,

Esta issue acabou de ser vinculada na(s) issue(s) https://totvsideia.atlassian.net/browse/CAPL-6385#icft=CAPL-6385, conforme menções feitas no campo description.

Automation for Jira 30 July 2024, 20:26 Jira Internal Users

@Robson Thanael Poffo ,
@Lucas Noetzold ,

Esta issue acabou de ser vinculada na(s) issue(s) https://totvsideia.atlassian.net/browse/CAPL-6385#icft=CAPL-6385, conforme menções feitas no campo description.

Automation for Jira 29 July 2024, 17:13 Jira Internal Users

@Robson Thanael Poffo ,
@MARCOS STUMPF ,
@Geny Isam Hamud Herrera ,
Esta issue foi planejada para ser entregue até 2024-08-02. Você pode confirmar consultando o campo Due Date desta issue.

Datas já planejadas para esta issue: 2024-08-02

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.

Automation for Jira 29 July 2024, 17:13 Jira Internal Users

Link para a thread da mensagem no Slack canal #emergencia