Histórico de mensagens sobre timeout em sugestões

EXIBINDO CONVERSAS RECENTES:

Texto: timeout
Canal: sugestões
Avatar discord do usuario anoni_mato

anoni_mato

tive uma ideia aqui. e se a GN mandar um request para webhookURL/txidmatch passando o txid recebido, com um timeout de uns 3 segundos, e o EC responde se a GN deve ou não aceitar o recebimento?

talvez o problema seja o BC encasquetar com o prazo de conclusão do recebimento (a média de tempo iria subir)

Avatar discord do usuario francisco.carvalho

francisco.carvalho

Ver Respostas

Boa tarde @everyone !

Retomando o assunto endpoint de configurações (https://www.notion.so/Endpoint-de-configura-es-0a97faee68f845ab96ec21551862fe6c).

Nosso time de engenharia observou que existem possíveis situações em que o match do regex com a string do txid pode demorar muitos segundos ou até minutos. Existem situações inclusive de crash da aplicação. Em outras palavras: não é seguro recebermos via input qualquer regex.

Um exemplo que vocês podem testar no browser:

let regexp = /^(\d+)$/;
let str = "012345678901234567890123456789z";
alert( regexp.test(str) );

O alert acima levará um longo tempo até que apareça. Imaginem isso no ato de recebimento de um Pix, no qual cada milisegundo é um fator determinante para um timeout inesperado.

A conclusão é que precisamos controlar melhor quais regex serão aceitas.

A proposta é, ao invés de receber um txidRegex, receber algo mais limitado que também atenda da mesma forma:

"recebimento": {
"txid": {
"comecaCom": "gnPix"
}
}

"recebimento": {
"txid": {
"terminaCom": "gnPix"
}
}

"recebimento": {
"txid": {
"contem": "gnPix"
}
}

comecaCom/terminaCom/contem: a-zA-Z0-9{0,15} //caracteres aceitos

Gostaria de opinião de vocês em relação a essa nova proposta, bem como sugestões dentro dessa nova abordagem.

Para quem interessar, uma referência sobre o assunto regexp-catastophic-backtracking com mais detalhes.
https://javascript.info/regexp-catastrophic-backtracking

Avatar discord do usuario francisco.carvalho

francisco.carvalho

Ver Respostas

{
"pix": {
"recebimentoManual": "aceitar",
"chaves": [{
"valor": "[email protected]",
"webhook": {
"notificar": {
"envio": true,
"recebimento": true,
"devolucao": true,
"recusa": true
},
"incluir": {
"tarifa": true
}
},
"recebimento": {
"txidRegex": "^[a-zA-Z0-9]+$"
}
}, {
"valor": "[email protected]",
"webhook": {
"notificar": {
"envio": false,
"recusa": false
}
}
}]
}
}

Definições:

Por default:
- Todas as notificações nascem habilitadas;
- Não há match de regex: aceita-se qualquer txid;
- Tarifa não é retornada;
- Pix Manual é acatado sempre;

Default em JSON

{
"pix": {
"recebimentoManual": "aceitar",
"chaves": [{
"valor": "[email protected]",
"webhook": {
"notificar": {
"envio": true,
"recebimento": true,
"devolucao": true,
"recusa": true
},
"incluir": {
"tarifa": true
}
},
"recebimento": {
"txidRegex": "" // se vazio, desconsiderar
}
}]
}

Observação
Quando de um envio de Pix: a notificação de webhook, em caso de status NAO_REALIZADO , poderá trazer o motivo da falha (PSP deu timeout, recusou, etc..). Em outro momento falaremos disso.

Avatar discord do usuario francisco.carvalho

francisco.carvalho

Ver Respostas

<@!522899003663450113> acredito que podemos assumir que, se webhook.notificar.envio for habilitado, a notificação do envio de Pix será enviada com a informação se foi sucesso ou falha. Em caso de falha, irá constar o motivo, que pode ser uma recusa ou timeout do PSP recebedor.