Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Erro na importação de status do pedido #57

Closed
matheusgnreis opened this issue Aug 24, 2021 · 23 comments
Closed

Erro na importação de status do pedido #57

matheusgnreis opened this issue Aug 24, 2021 · 23 comments
Labels
question Further information is requested

Comments

@matheusgnreis
Copy link
Member

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:

Screenshot 2021-08-24 at 10-30-49 ecom-bling – Console do Firebase
@leomp12
Copy link
Member

leomp12 commented Aug 24, 2021 via email

@leomp12
Copy link
Member

leomp12 commented Aug 24, 2021 via email

@leomp12
Copy link
Member

leomp12 commented Aug 24, 2021

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

Screenshot 2021-08-24 at 14-40-23 ecom-bling – Cloud Firestore – Console do Firebase

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

Screenshot 2021-08-24 at 14-43-42 ecom-bling – Console do Firebase

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
Copy link
Member

leomp12 commented Aug 24, 2021

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 leomp12 added the question Further information is requested label Aug 24, 2021
@leomp12
Copy link
Member

leomp12 commented Aug 24, 2021

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...

@leomp12 leomp12 closed this as completed Aug 26, 2021
@matheusgnreis
Copy link
Member Author

Um caso de hoje: Houve um callback do bling

Screenshot 2021-08-26 at 16-39-36 ecom-bling – Console do Firebase

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

image

@leomp12
Copy link
Member

leomp12 commented Aug 26, 2021

Screenshot 2021-08-26 at 16-58-20 ecom-bling – Cloud Firestore – Console do Firebase

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
Copy link
Member

leomp12 commented Aug 26, 2021

Só pra contrapor, um pedido atendido:

Screenshot 2021-08-26 at 17-01-14 ecom-bling – Cloud Firestore – Console do Firebase

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
Copy link
Member

leomp12 commented Aug 26, 2021

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
Copy link
Member Author

Problema que esse que mandei teve notificação
image

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
Copy link
Member Author

matheusgnreis commented Aug 26, 2021 •
edited
Loading

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
Copy link
Member

leomp12 commented Aug 26, 2021

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:

Screenshot 2021-08-26 at 17-36-02 ecom-bling – Console do Firebase

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?

@leomp12 leomp12 reopened this Aug 26, 2021
@matheusgnreis
Copy link
Member Author

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
Copy link
Member

leomp12 commented Aug 26, 2021 •
edited
Loading

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
Copy link
Member

leomp12 commented Aug 26, 2021

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

Que bela bosta em 😬

@matheusgnreis
Copy link
Member Author

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
Copy link
Member

leomp12 commented Aug 26, 2021 •
edited
Loading

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
Copy link
Member

leomp12 commented Aug 26, 2021

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
Copy link
Member Author

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

@matheusgnreis
Copy link
Member Author

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

leomp12 added a commit that referenced this issue Aug 28, 2021
@leomp12
fix(bling-callback): try to delay and queue order callbacks [#57]
563379d
leomp12 added a commit that referenced this issue Aug 28, 2021
@leomp12
fix(bling-callback): end process (clear proceed timer) when new tmp h…
22a2835 
…as more orders only [#57]

start doc subscription after document set
@leomp12
Copy link
Member

leomp12 commented Aug 28, 2021

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

@matheusgnreis
Copy link
Member Author

Beleza, valeu

@leomp12
Copy link
Member

leomp12 commented Sep 30, 2021

#62

@leomp12 leomp12 closed this as completed Sep 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question Further information is requested
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@leomp12 @matheusgnreis