Requisição sem resposta em casos de erro

[leomp12]

Como está atualmente, o create transaction não responde em caso de status diferente de 400, 401, 403 ou maior que 500, inclusive não responde caso a requisição no PagSeguro dê timeout. Além disto, mesmo com status 400 existem ocasiões em que não há resposta da requisição, se não bater um header ou se não houver data da resposta de erro do PagSeguro.

Não pode acontecer de a request ficar sem resposta, em geral temos que deixar um fallback no final do última catch com uma resposta de erro genérica.

Acredito que eu tinha fixado o tratamento de erro, inclusive debugs, neste commit https://github.com/ecomplus/app-pagseguro/commit/f835b8c440f29b89b7370a6072d4a3ffaf3e621c , mas depois ele acabou sendo sobrescrito neste commit seu @talissonf https://github.com/ecomplus/app-pagseguro/commit/fd28ce21a64a5ce591ff4b828be710b228ed21cd , teve outras alterações no commit então nem sei se foi realmente intencional ou foi por tabela quando deu conflitos.

[talissonf]

Então segundo a documentação do pagseguro os status respondidos pela api são os seguintes; 200, 400, 401. Aparentemente o status 403 no pagseguro é 500.

https://dev.pagseguro.uol.com.br/docs/erros https://dev.pagseguro.uol.com.br/reference/checkout-transparente

[leomp12]

Sim, mas também precisamos de um fallback pra status que eles não documentam, geralmente esse pessoal não segue tanto assim a documentação :grimacing:

[leomp12]

Vou bater em log status de erros conhecidos também mas sem o payload todo e no log em vez do error, mais resumido pra não flodar, porque segue dando uns erros lá sem registro...

[leomp12]

Na real tá dando é o auth not found pelo jeito :neutral_face: Isto precisava ir pra log também pra conseguirmos identificar e alertar o lojista com urgência...