Erro na importação de status do pedido

[matheusgnreis]

Descreva o erro O status do pedido foi alterado no bling, o mesmo chegou na plataforma, pois temos no log:

10:05:35.929 AM

Starting #1077 ___importation/order_numbers/6047

Até encontrou o pedido:

10:05:37.253 AM

1077 found order 6047

Mas o status não foi alterado.

Não mostra nenhum erro posterior, ao filtrar por esse evento:

[leomp12]

O found order nesse trecho não tem relação com o callback do Bling, são execuções diferentes. Você buscou nos logs pelo número do pedido?

Em ter., 24 de ago. de 2021 10:32, Matheus Reis @.***> escreveu:

Descreva o erro O status do pedido foi alterado no bling, o mesmo chegou na plataforma, pois temos no log:

10:05:35.929 AM

Starting #1077 ___importation/order_numbers/6047

Até encontrou o pedido:

10:05:37.253 AM

1077 found order 6047

Mas o status não foi alterado.

Não mostra nenhum erro posterior, ao filtrar por esse evento:

[image: Screenshot 2021-08-24 at 10-30-49 ecom-bling – Console do Firebase] https://user-images.githubusercontent.com/35343551/130625440-6ca2c7a3-9ffc-4aac-9c08-752e85acbc35.png

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ecomplus/app-bling-erp/issues/57, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACOZELGGK2Y2NBVQUAJZRC3T6ONN5ANCNFSM5CW3FHCA .

[leomp12]

Aliás, pelo número e depois pelo ID do pedido?

Em ter., 24 de ago. de 2021 10:38, Leonardo Matos @.***> escreveu:

O found order nesse trecho não tem relação com o callback do Bling, são execuções diferentes. Você buscou nos logs pelo número do pedido?

Em ter., 24 de ago. de 2021 10:32, Matheus Reis @.***> escreveu:

Descreva o erro O status do pedido foi alterado no bling, o mesmo chegou na plataforma, pois temos no log:

10:05:35.929 AM

Starting #1077 ___importation/order_numbers/6047

Até encontrou o pedido:

10:05:37.253 AM

1077 found order 6047

Mas o status não foi alterado.

Não mostra nenhum erro posterior, ao filtrar por esse evento:

[image: Screenshot 2021-08-24 at 10-30-49 ecom-bling – Console do Firebase] https://user-images.githubusercontent.com/35343551/130625440-6ca2c7a3-9ffc-4aac-9c08-752e85acbc35.png

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ecomplus/app-bling-erp/issues/57, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACOZELGGK2Y2NBVQUAJZRC3T6ONN5ANCNFSM5CW3FHCA .

[leomp12]

Nesse momento que você mencionou o status que tínhamos do Bling era "em aberto":

O último callback do Bling que encontrei pra essa loja e esse pedido de fato foi o das 10:05:

Nesse momento o pedido foi enfileirado (como você viu nos logs) e lido no Bling, o retorno do Bling então é salvo temporariamente no Firestore como mostrei no primeiro print, nesse momento o Bling retornou que o pedido estava em aberto, por isso não foi alterado na plataforma.

[leomp12]

Sugiro que você leia diretamente a API do Bling para ver o status do pedido lá nesse momento, se ele estiver com outro status tente verificar o horário da alteração.

Se o horário da alteração for depois das 10:05 parece que não recebemos o último callback, se o alteração foi de fato às 10:05 eu acho que tinha algum problema na API deles, talvez só um cache na leitura, fato é que eles retornaram nessa ocasião que o pedido estava em aberto (nas palavras do próprio Bling).

Como a gente só pega isso da resposta deles, não tem como brotar um em aberto no doc do Firestore se eles não retornarem exatamente isso.

[leomp12]

Vou manter o issue pro caso de você ter mais alguma informação ou dúvida, se não acho que ele pode ser fechado, até então me parece que o app executou o que deveria executar com os dados que recebeu...

[matheusgnreis]

Um caso de hoje: Houve um callback do bling

No histórico pela API consta como:

                            "ocorrencia": {
                                "dataCriacaoPedido": "2021-08-25 08:08:44",
                                "data": "2021-08-26 11:38:00",
                                "ocorrencia": "",
                                "situacao": "Enviado"
                            }

11:39 a fila já estava vazia e aparentemente não foi processado, ou foi e não notificou com esse status ai de cima

[leomp12]

No histórico pela API consta como:

O situacao: Enviado aí acredito que seja o status do webhook, de fato foi enviado e recebido.

O pedido não foi alterado porque, novamente, o webhook veio com a situação em aberto, basta você olhar no Firestore...

[leomp12]

Só pra contrapor, um pedido atendido:

O que fica salvo aí é exatamente a string que o Bling envia, sem tirar nem por nada, se ele envia em aberto eu vou acreditar que o pedido ainda está em aberto então ele não vai ser alterado..

[leomp12]

Te explicar, ele salva no banco a última situação lida no Bling e processada com sucesso, se chega outro webhook ele bota o pedido na fila de novo e processa, se a situacao do Bling estiver igual ele encerra o processo sem fazer nada, se a situação estiver diferente ele processa e salva de novo no Firestore...

[matheusgnreis]

Problema que esse que mandei teve notificação

E até apareceu na lista pra importar . O que mostrou ai no firebase é do dia 25, a que eu tenho aqui é do dia 26. Por isso falei que acho que elas estão se perdendo em algum momento.

[matheusgnreis]

Se clicar na imagem acima, o registro da atualização da venda é dia 26/08 às 11:38. O último registro do firebase é 25/08 pela imagem que mostrou

[leomp12]

Ele salva no Firestore quando a situação muda né, se receber duas notificações da mesma situação não altera no Firestore não. De qualquer forma, nesse caso aí parece que perdeu mesmo porque de fato não achei o log do início da importação desse número de pedido, e acho que foi por isso aqui:

O Bling enviou 3 notificações no mesmo intervalo de segundo, acho que nisso aí foi sobrescrevendo quando tentou salvar a fila no app. Até dá pra dar um jeito nisso, mas o ideal era não receber esses webhooks desse jeito não muito inteligente (até pra economizar custo computacional), tá salvo o tal do enviar em lote deles?

[matheusgnreis]

Aparentemente o envio em lote, só tem como habilitar para estoques. As outras duas opções não. Então pode ser que eles tenham enviado ou não. Pelo que me falou, ele alterou no bling 8 pedidos pra enviado de uma vez, coincidentemente 7 foram lidos e o último não. Diz ele que terça ocorreu o mesmo enviou 4 e 3 foram. Mas pelo visto é o tempo de envio da notificações

[leomp12]

Deixe o envio de lotes desativado e salve as configurações realizadas.

Na descrição do app (desde essa alteração) eu vi que vocês pedem pra desativar, por que exatamente?

Todos os testes que eu fiz na época foram com isso ativo, para o webhook de estoque desde esse commit até faz sentido não ser em lote para quem altera muitos SKUs ao mesmo tempo, mas para os pedidos sempre vai ser melhor estar ativo o enviar dados em lote deles.

[leomp12]

Aparentemente o envio em lote, só tem como habilitar para estoques.

Que bela bosta em 😬

[matheusgnreis]

Na descrição do app (desde essa alteração) eu vi que vocês pedem pra desativar, por que exatamente?

Porque se a alteração for grande, eles enviam os 10 ou 20 ou 100 de uma vez e espera que você trate essa informação e retorne com 30000ms, se não retorna nada, eles falaram que deu erro e por ser 10 itens por exemplo, eles já desativam o callback, considerando que enviaram 10 notificações, deu erro nas 10 e ai a loja fica sem receber as notificações.

[leomp12]

Porque se a alteração for grande, eles enviam os 10 ou 20 ou 100 de uma vez e espera que você trate essa informação e retorne com 30000ms

Então, depois desse commit e antes desse, 100 SKUs daria 33s realmente.

Antes de todos esses commit só salvava na fila então demoraria Nms independente do número de SKUs, já agora sempre retorna 200 de cara antes mesmo de buscar o app na E-Com então tbm tanto faz quantos SKUs tem.

A limitação aí é timout da cloud function, 60s portanto, até cerca de 150 SKUs de uma vez é tranquilo e certamente melhor do que 1 a 1 no mesmo segundo 😐

[leomp12]

Mas eu até tinha mencionado que:

para o webhook de estoque desde esse commit até faz sentido não ser em lote para quem altera muitos SKUs ao mesmo tempo, mas para os pedidos sempre vai ser melhor estar ativo o enviar dados em lote deles.

Pedido só pega e salva na fila, logo tanto faz quantos pedidos chegam de uma vez.

[matheusgnreis]

Aparentemente envio em lote só pra estoque. Vou pedir pra colocar de novo

[matheusgnreis]

Pra envio de pedido, não tem possibilidade de envio em lote. Só se for internamente lá, vou perguntar

[leomp12]

Só pra constar, alguns pedidos hoje não foram importados depois do commit de madrugada, dei esse fix agora e tô acompanhando.

[matheusgnreis]

Beleza, valeu

[leomp12]

https://github.com/ecomplus/app-bling-erp/issues/62