Em nosso ambiente possuímos integração do ERP com a VTEX. E desde sexta (16/02) por volta das 7h, o nossa integração tem retornado a mensagem ‘Connection timed out’ ocasionalmente, quando tenta atualizar o estoque da VTEX, através do PUT. O timed out é intermitente, não acontece sempre para o mesmo SKU, mas em toda execução ao menos 1 sku retorna com timed out.
Gostaria de saber se houve alguma atualização na VTEX no dia 16/02 que possa estar interferindo no tempo de resposta, ou se estão com alguma intermitência nos serviços.
Victor, não tivemos relatos de nenhuma atualização nesse dia! Mas pode ser que estejamos nos deparando com um caso de throttling, não encontrei nada específico para esta API, mas posso verificar com o time quais são os limites.
Consegue me dizer em média quantos SKUs são atualizados ao mesmo tempo, ou em qual intervalo de tempo isso ocorre?
Temos em média 440 SKUs sendo atualizados por execução.
Nosso sistema está configurado para executar a integração (integração de pedidos e estoque) de 20 em 20 minutos, cada execução demora cerca de 7 a 10 minutos para finalizar.
A documentação da VTEX não divulga os limites para suas APIs, mas informam que estes limites podem variar dependendo do dia.
Por isso, o mais recomendável é sempre olhar para o header do response da requisição para ver se existe alguma informação sobre algum limite atingido, antes de enviar a próxima requisição.
Qual o código do erro retornado para estas requisições que acabam falhando? Seria um 522?
Sobre o código retornado: Não retorna código, somente a mensagem “Connection Timed Out”.
Para exemplificar, seguem três exemplos de logs que recebemos:
ID 9 : Connection timed out.
ID 40 : 403 Forbidden
ID 193 : 500 InternalServerError
Configuramos uma geração de log onde o ID é o produto que deu erro e em seguida o código de erro retornado. Como pode ver, o “Connection timed out” que me refiro, não retorna o código, apenas a descrição do erro.
Acho que o ideal nesse cenário é tentar entender cada erro separadamente.
Connection timed out é um erro que pode ocorrer por causa do throttling mesmo, mas normalmente ele vem com o código 429. Verifiquei com o nosso time e nesse caso a recomendação é que, de fato não temos um valor para referência, nesse caso o ideal é espaçar mais as suas chamadas.
403 Forbidden é um erro atrelado a permissões, o que me parece estranho quando ele só ocorre com um único SKU.
500 InternalServerError é um erro que normalmente ocorre quando a requisição está elaborada de forma incorreta, algum header errado, algum valor incorreto.
O estranho é que você relatou que esses erros acontecem para diferentes SKUs toda vez que você faz a atualização de estoque, certo?
Exatamente, é isso que estamos estranhando também, não é sempre para o mesmo SKU. Vezes acontece com apenas 1 SKU, as vezes com 4 SKUs diferentes, as vezes com 2… não conseguimos identificar um padrão.
O único padrão que identificamos na verdade, é que depois do dia 16/02, toda execução está vindo com ao menos 1 SKU com esse erro de time out. Antes dessa data, ocorria mais o erro 403, mas era esporádico. Por isso suspeitamos de alguma alteração/incidente por parte da VTEX, ou algum gargalo nos serviços deste lado.
Talvez o espaçamento entre as chamadas seja uma possibilidade. Teremos que analisar e testar internamente a alteração no fonte.
@KarinaMota, apenas retornando com atualizações sobre o caso relatado.
Tentamos acrescentar um espaçamento entre os produtos, chegamos a colocar até 1,5 segundos entre produtos, mas o erro de Connection Timed Out persistiu para alguns SKU’s (mudando de sku com erro em casa execução, da mesma forma que estava no meu relato anterior). E se aumentássemos mais ainda o espaçamento, o nosso programa de atualização de estoque demoraria mais de 20minutos para finalizar, então acreditamos que, para o nosso caso, não seria eficiente dessa forma.
A solução que encontramos e que aparentemente se tornou viável, segundo nossos testes, foi semelhante a recomendação do @andremiani:
Já analisávamos os retornos de erro, porém acrescentamos em nosso fonte uma condição para esse erro em específico. No retorno de cada tentativa de atualização (PUT), caso o erro vier com a descrição “Connection Timed Out.” o programa irá tentar enviar outro PUT, caso o erro persista após 3 tentativas, ai sim o erro é registrado em nosso log de erros.
Obs.: Durante nossos testes, ao recebermos o erro de Connection Timed Out, em 100% das vezes, na tentativa seguinte já era retornado positivo, sem a necessidade das 3 tentativas.
Aplicamos a solução que comentei em produção.
E somente para informar que, o código 429 que você comentou, recebemos esse retorno hoje e vem com a descrição “429 TooManyRequests”, conforme recebemos no log:
ID 169 : 429 TooManyRequests
Ou seja, o “Connection Timed Out” deve ser outro tipo de erro e ele realmente não vem com código, apenas descrição. Pela descrição, o 429 realmente é um caso de throttling, mas ainda fica a dúvida do motivo do Timed Out