• 0
Sign in to follow this  
Diogenes Lima

Inconsistência ao consultar pagamentos recebidos

Question

A consulta aos pagamentos recebidos é muito inconsistente, principalmente com usuários com um número grande de pagamentos. Eu preciso importar todos os pagamentos recebidos por um usuário e utilizo:

 

https://api.mercadolibre.com/collections/search?access_token=APP_USR-XXXX&offset=0&limit=100

 

O retorno contém:

{  "paging": {    "total": 20031,    "limit": 100,    "offset": 0  },  "results": []}

Vou alterando o offset, de 100 em 100, porém às vezes para o mesmo usuário recebo uma quantidade total diferente de antes e menor do que o que já processei. Ex:

 

https://api.mercadolibre.com/collections/search?access_token=APP_USR-XXXX&offset=5000&limit=100

{  "paging": {    "total": 774,    "limit": 100,    "offset": 5000  },  "results": [  ]}

Aí meu processamento para, uma vez que pela lógica, já teria ultrapassado o total. Porém se eu insistir e chamar a mesma URL, o resultado vem diferente:

 

https://api.mercadolibre.com/collections/search?access_token=APP_USR-XXXX&offset=5000&limit=100

{  "paging": {    "total": 20347,    "limit": 100,    "offset": 5000  },  "results": []}

Note que o total é maior que a segunda chamada e maior ainda que a primeira. O caso piora ao chegar no número mágico de offset 10100. Só recebo isto como retorno :

 

https://api.mercadolibre.com/collections/search?access_token=APP_USR-XXXX&offset=10100&limit=100

{  "message": "Service unavailable",  "error": "Service unavailable",  "status": 500,  "cause": {    "code": "U001",    "message": "Service Unavailable"  }}

ou isto:

https://api.mercadolibre.com/collections/search?access_token=APP_USR-XXXX&offset=10100&limit=100

{  "message": "Invalid search parameter",  "error": "bad_request",  "status": 400,  "cause": null}

Só para reforçar todas as chamadas foram feitas para o mesmo usuário.

 

Alguém pode me dar uma luz sobre isso e o que pode ser feito?

Share this post


Link to post
Share on other sites

21 answers to this question

Recommended Posts

  • 0

lamento muito pelo equívoco, li errado sua descrição e te chamei a atenção por algo que você está fazendo certo.

 

Uma coisa chama a atenção: não há parâmetros de filtro ou ordenamento na sua consulta. Isto não é algo que possa causar estas divergências.

 

Vi que fez 2 vezes com os mesmos parâmetros e voltaram valores diferentes, isto realmente está errado

Share this post


Link to post
Share on other sites
  • 0

isto está relacionado com o tipo de distribuição dos dados nos servidores do ML e sua disponibilidade, algo muito comum nos bancos de dados modernos...

 

provavelmente dados mais antigos não tenham prioridade na disponibilidade (afinal não é comum consultar um pagamento de meses atrás frequentemente)

Share this post


Link to post
Share on other sites
  • 0

lamento muito pelo equívoco, li errado sua descrição e te chamei a atenção por algo que você está fazendo certo.

 

Uma coisa chama a atenção: não há parâmetros de filtro ou ordenamento na sua consulta. Isto não é algo que possa causar estas divergências.

 

Vi que fez 2 vezes com os mesmo parâmetros e voltaram valores diferentes, isto realmente está errado

Sim, é muito inconsistente. Vem um erro, mas se eu insistir chamando com os mesmos parâmetros, tem hora que vêm os dados corretos. Com relação ao filtro, realmente não tem, porque preciso de todos, mas eu uso ordenação no meu processamento normal e dá o erro do mesmo jeito. Eu ordeno por data aprovação decrescente, assim tento garantir que pelo menos os últimos pagamentos estão no sistema. Só não coloquei no exemplo para não poluir demais a url.

 

isto está relacionado com o tipo de distribuição dos dados nos servidores do ML e sua disponibilidade, algo muito comum nos bancos de dados modernos...

 

provavelmente dados mais antigos não tenham prioridade na disponibilidade (afinal não é comum consultar um pagamento de meses atrás frequentemente)

Pois é, mas é um erro grave ao meu ver. E não é questão de consultar dados de meses atrás, embora eu não veja problema nisso. Em Orders não acontece isso e já fiz importação de mais de 30000 do mesmo cliente. Tenho clientes com mais de 10000 vendas no mês. Não consigo importar os pagamentos do mês, porque não consigo estabelecer uma lógica para resolver isso. Além disso não ocorre apenas com pagamentos antigos nem com quem tem muitos pagamentos. Tenho casos de dar o erro logo com offset 200. Outro problema é que acima de 10000 sempre dá erro, não importa quantas vezes eu refaça a consulta.

Share this post


Link to post
Share on other sites
  • 0

Você levantou a bola e fui fazer uns testes.

Aí fiz um while com um foreach para consultar os dados retornados (3850 aproximadamente), e eis que entre o 299 e o 499 deu:

Array
(
[body] => stdClass Object
(
[paging] => stdClass Object
(
[total] => 43
[limit] => 100
[offset] => 299
)

[results] => Array
(
)

)

[httpCode] => 200
)

Mas depois disso ele continuou (!)

Share this post


Link to post
Share on other sites
  • 0

Você levantou a bola e fui fazer uns testes.

Aí fiz um while com um foreach para consultar os dados retornados (3850 aproximadamente), e eis que entre o 299 e o 499 deu:

Array

(

[body] => stdClass Object

(

[paging] => stdClass Object

(

[total] => 43

[limit] => 100

[offset] => 299

)

 

[results] => Array

(

)

 

)

 

[httpCode] => 200

)

 

Mas depois disso ele continuou (!)

 

O que você quiser dizer com o "Mas depois disso ele continuou"? Qual seria a lógica usada para um processo continuar processando algo, sendo que a resposta indica que já teria passado da quantidade máxima?

 

Eu uso algo assim:

Se ((offset + processados) < total) -> continua e incrementa processados

Se não, finaliza

 

Até pensei em armazenar o maior valor retornado em total, mas como citei, é muito inconsistente e corro o risco de cair em um loop infinito, principalmente porque a partir do offset 10100, sempre dá o erro. Aí fico colocando estruturas de controle prá saber quantas vezes já deu o erro e aí sair da rotina após X erros, porém tem hora que na segunda chamada já vem o dado correto e tem hora que posso chamar 10 vezes e continua o erro.

Share this post


Link to post
Share on other sites
  • 0

O que você quiser dizer com o "Mas depois disso ele continuou"? Qual seria a lógica usada para um processo continuar processando algo, sendo que a resposta indica que já teria passado da quantidade máxima?

 

Eu uso algo assim:

Se ((offset + processados) < total) -> continua e incrementa processados

Se não, finaliza

 

Até pensei em armazenar o maior valor retornado em total, mas como citei, é muito inconsistente e corro o risco de cair em um loop infinito, principalmente porque a partir do offset 10100, sempre dá o erro. Aí fico colocando estruturas de controle prá saber quantas vezes já deu o erro e aí sair da rotina após X erros, porém tem hora que na segunda chamada já vem o dado correto e tem hora que posso chamar 10 vezes e continua o erro.

 

a lógica é bem simples, é como o rodrigojob disse: use o offset inicial, pule os problemáticos, repita o processo

Share this post


Link to post
Share on other sites
  • 0

Não é tão simples assim. Eu já fiz desta forma, mas acabo caindo em outros problemas.

 

Nem sempre a primeira chamada me retorna o total correto daquele cliente. Além disso acima de offset 10100 sempre dá erro.

 

Vocês sabem se algum desenvolvedor ou mantenedor da API frequenta o fórum e como faço para marcá-lo aqui?

Share this post


Link to post
Share on other sites
  • 0

Não é tão simples assim. Eu já fiz desta forma, mas acabo caindo em outros problemas.

 

Nem sempre a primeira chamada me retorna o total correto daquele cliente. Além disso acima de offset 10100 sempre dá erro.

 

Vocês sabem se algum desenvolvedor ou mantenedor da API frequenta o fórum e como faço para marcá-lo aqui?

 

Olá Diogenes!

 

por isso você deve sempre refazer a chamada de tempos em tempos, para pegar itens que ficaram fora da cnsulta, o que pode ser facilmente comparado pois os IDs são fixos (temos clientes com grandes volumes de vendas, não temos este problema com os offsets maiores que 10100, provavelmente esteja relacionado a forma da consulta)

 

o MercadoLivre (assim como nós) utiliza bancos de dados modernos, espalhados em diversos clusters (o que é fundamental para grandes volumes de dados), neste tipo de armazenamento os DBs focam em disponibilidade ou fidelidade de dados (não sendo possível os dois ao mesmo tempo), no caso de pagamentos a fidelidade é fundamental (não podem haver inconsistências), sendo normal em determinados momentos alguns dados ficarem indisponíveis para consulta por curtos períodos ... isso não é exclusividade do ML, ocorre em praticamente todo sistema desse porte

 

quanto ao pessoal interno do ML, eles passam esporadicamente, não costumam frequentar muito o fórum

Share this post


Link to post
Share on other sites
  • 0

Olá Diogenes!

 

por isso você deve sempre refazer a chamada de tempos em tempos, para pegar itens que ficaram fora da cnsulta, o que pode ser facilmente comparado pois os IDs são fixos (temos clientes com grandes volumes de vendas, não temos este problema com os offsets maiores que 10100, provavelmente esteja relacionado a forma da consulta)

 

o MercadoLivre (assim como nós) utiliza bancos de dados modernos, espalhados em diversos clusters (o que é fundamental para grandes volumes de dados), neste tipo de armazenamento os DBs focam em disponibilidade ou fidelidade de dados (não sendo possível os dois ao mesmo tempo), no caso de pagamentos a fidelidade é fundamental (não podem haver inconsistências), sendo normal em determinados momentos alguns dados ficarem indisponíveis para consulta por curtos períodos ... isso não é exclusividade do ML, ocorre em praticamente todo sistema desse porte

 

quanto ao pessoal interno do ML, eles passam esporadicamente, não costumam frequentar muito o fórum

 

 

Não é tão simples assim. Eu já fiz desta forma, mas acabo caindo em outros problemas.

 

Nem sempre a primeira chamada me retorna o total correto daquele cliente. Além disso acima de offset 10100 sempre dá erro.

 

Vocês sabem se algum desenvolvedor ou mantenedor da API frequenta o fórum e como faço para marcá-lo aqui?

 

Dou razão aos 2 com ressalva

 

Bem, sei que há clusterização, porém o ML deve, então, disponibilizar os dados de outra forma, por exemplo agendada. 

O que não pode é retornar dados inconsistentes, pois a base de dados e o serviço perdem confiabilidade.

Share this post


Link to post
Share on other sites
  • 0

Dou razão aos 2 com ressalva

 

Bem, sei que há clusterização, porém o ML deve, então, disponibilizar os dados de outra forma, por exemplo agendada. 

O que não pode é retornar dados inconsistentes, pois a base de dados e o serviço perdem confiabilidade.

 

Concordo com você, Rodrigo. Não acho aceitável este comportamento da API. Entendo a questão de clusterização, mas isso não acontece com "Orders", por exemplo. O grande problema é ter que ficar criando mecanismos de tratamento para contornar essas coisas.

 

Eu não uso desta forma, mas imaginem que alguém faça uma aplicação que consulte e faça paginação dos pagamentos acessando a API diretamente. Aí chega uma hora que dá erro e não vem nenhum resultado. Você mostra para o usuário uma tela com a informação que ele precisa tentar de novo, e de novo, e de novo e uma hora os dados que ele quer serão retornados. O usuário vai achar que sua aplicação é uma porcaria, pois ele não tem conhecimento que o erro está na API do ML.

Share this post


Link to post
Share on other sites
  • 0

... imaginem que alguém faça uma aplicação que consulte e faça paginação dos pagamentos acessando a API diretamente. Aí chega uma hora que dá erro e não vem nenhum resultado. Você mostra para o usuário uma tela com a informação que ele precisa tentar de novo, e de novo, e de novo e uma hora os dados que ele quer serão retornados. O usuário vai achar que sua aplicação é uma porcaria, pois ele não tem conhecimento que o erro está na API do ML.

 

Neste caso o cliente teria oda a razão e a aplicação dessa pessoa realmente é uma "porcaria", pois depender somente dos dados de terceiros e não estar preparado para falhas é extremamente amador e perigoso

 

Não acho aceitável este comportamento da API. Entendo a questão de clusterização, mas isso não acontece com "Orders", por exemplo. O grande problema é ter que ficar criando mecanismos de tratamento para contornar essas coisas.

 

Sim, é aceitável, posso dizer isso como engenheiro de software ... o que você espera é utópico em qualquer aplicação de alta escalabilidade da atualidade... além disso não se pode comparar "orders" com "payments", o nível de aceitação de inconsistência em uma order é muito maior que em um payment ... nós mesmo utilizamos diferentes bancos de dados para cada tipo de finalidade dentro de uma mesma aplicação, de acordo com a necessidade de disponibilidade, tolerância a falhas, estrutura flexível, etc...

 

Criar mecanismos de tratamento são fundamentais para aplicações voltadas para o Mercado Livre, assim como para outros Marketplaces ou qualquer outro tipo de aplicação imaginável... faz parte do nosso trabalho...  lembrando ainda que a informação está lá, ela não "some", somente a consulta é que fica por instantes inconsistente

Share this post


Link to post
Share on other sites
  • 0

Dou razão aos 2 com ressalva

 

Bem, sei que há clusterização, porém o ML deve, então, disponibilizar os dados de outra forma, por exemplo agendada. 

O que não pode é retornar dados inconsistentes, pois a base de dados e o serviço perdem confiabilidade.

 

grande rodrigojob, uma solução seria disponibilizarem exportação em massa, mas acredito que não fazem isso pois o uso indevido da função sobrecarregaria a plataforma

 

aliás acredito que não disponibilizam muitas coisas pelo simples fato de muitos desenvolvedores e também vendedores utilizarem os recursos de forma indevida... o que acaba prejudicando os demais

Share this post


Link to post
Share on other sites
  • 0

Neste caso o cliente teria oda a razão e a aplicação dessa pessoa realmente é uma "porcaria", pois depender somente dos dados de terceiros e não estar preparado para falhas é extremamente amador e perigoso

 

 

Sim, é aceitável, posso dizer isso como engenheiro de software ... o que você espera é utópico em qualquer aplicação de alta escalabilidade da atualidade... além disso não se pode comparar "orders" com "payments", o nível de aceitação de inconsistência em uma order é muito maior que em um payment ... nós mesmo utilizamos diferentes bancos de dados para cada tipo de finalidade dentro de uma mesma aplicação, de acordo com a necessidade de disponibilidade, tolerância a falhas, estrutura flexível, etc...

 

Criar mecanismos de tratamento são fundamentais para aplicações voltadas para o Mercado Livre, assim como para outros Marketplaces ou qualquer outro tipo de aplicação imaginável... faz parte do nosso trabalho...  lembrando ainda que a informação está lá, ela não "some", somente a consulta é que fica por instantes inconsistente

 

Eu discordo de você na primeira parte. A questão não é não estar preparado para falhas. E sim que as falhas apresentadas vão sempre estourar na ponta, vide o caso das etiquetas do ML que são geradas acessando o sistema dos Correios. As pessoas não vão reclamar para os Correios que as etiquetas não estão sendo geradas. Elas reclamam no ML. O mesmo princípio para os rastreios dos Correios. Tem muitas aplicações que consultam os dados dos Correios e armazenam o resultado lá. Para alguns casos pode fazer sentido, mas qual a vantagem em armazenar 100% destes dados se eles não forem consultados e quando existir essa necessidade eles podem ser consultados pelo sistema dos Correios na hora?

 

Além disso não faz muito sentido ter acesso a uma API e ter que importar 100% dos dados para a sua base. Em nenhum local a API informa que os dados podem não ser consistentes.

 

Já na segunda parte acho que você cai em uma contradição, pois você diz que que em orders a inconsistência aceitável é maior. Concordo com isso, porém em orders estas inconsistências não ocorrem. Elas só acontecem em Pagamentos, que deveriam ter uma inconsistência aceitável menor, afinal são dados financeiros.

Quanto à disponibilidade dos dados, o ML já faz isso limitando o acesso aos dados antigos. Se não me engano apenas os dados dos últimos 6 meses ficam disponíveis.

 

Respeito suas opiniões, mas discordo em parte. Na minha opinião isto é um erro da API e não uma característica.

Share this post


Link to post
Share on other sites
  • 0

Eu discordo de você na primeira parte. A questão não é não estar preparado para falhas. E sim que as falhas apresentadas vão sempre estourar na ponta, vide o caso das etiquetas do ML que são geradas acessando o sistema dos Correios. As pessoas não vão reclamar para os Correios que as etiquetas não estão sendo geradas. Elas reclamam no ML. O mesmo princípio para os rastreios dos Correios. Tem muitas aplicações que consultam os dados dos Correios e armazenam o resultado lá. Para alguns casos pode fazer sentido, mas qual a vantagem em armazenar 100% destes dados se eles não forem consultados e quando existir essa necessidade eles podem ser consultados pelo sistema dos Correios na hora?

 

Além disso não faz muito sentido ter acesso a uma API e ter que importar 100% dos dados para a sua base. Em nenhum local a API informa que os dados podem não ser consistentes.

se a falha para seu sistema é um ponto crítico, então deve estar preparado para elas, e os clientes tem razão de reclamar, uma vez que seus clientes PAGAM para você por esse serviço, o qual o Mercado Livre te disponibiliza GRATUITAMENTE (a API é grátis, assim como a dos Correios)

 

vai do bom senso de investir em uma infraestrutura para garantir a disponibilidade desses dados... aqui armazenamos tudo, com revisões de cada alteração, garantindo 99,98% de disponibilidade... afinal não podemos culpar os Correios ou o Mercado Livre por um serviço gratuíto

 

 

Já na segunda parte acho que você cai em uma contradição, pois você diz que que em orders a inconsistência aceitável é maior. Concordo com isso, porém em orders estas inconsistências não ocorrem. Elas só acontecem em Pagamentos, que deveriam ter uma inconsistência aceitável menor, afinal são dados financeiros.

Quanto à disponibilidade dos dados, o ML já faz isso limitando o acesso aos dados antigos. Se não me engano apenas os dados dos últimos 6 meses ficam disponíveis.

 

Respeito suas opiniões, mas discordo em parte. Na minha opinião isto é um erro da API e não uma característica.

 

acredito que faltou entendimento deste tipo de arquitetura de sua parte, pois não houve contradição, a tolerância a falhas é inversamente proporcional a disponibilidade... quanto mais tolerante a falhas, mais disponíveis ficam os dados, e vice versa

 

acredito que há muito a se melhorar na API do Mercado Livre, mas não vejo este ponto como uma falha do ponto de visa estrutural

Share this post


Link to post
Share on other sites
  • 0

MLDEV,

 

não concordo que deva ter tolerância com falhas no serviço.

 

E entendo que ele seja aparentemente gratuito, a comissão de venda paga este serviço.

É muito conveniente apontar que o custo de comissão de venda é apenas para anúncio, pois o percentual de impostos é pequeno. Se fosse cobrado pelo MercadoPago a transação teria IOF, um percentual maior de impostos, ....

 

A disponibilização da API é para que viabilize a operação de grandes players, que seria hérculeo operar com o front-end, e muito mais passível de fraude por parte de funcionários.

 

Grátis não é.

 

Até mais,

Rodrigo

Share this post


Link to post
Share on other sites
  • 0

MLDEV,

 

não concordo que deva ter tolerância com falhas no serviço.

 

E entendo que ele seja aparentemente gratuito, a comissão de venda paga este serviço.

É muito conveniente apontar que o custo de comissão de venda é apenas para anúncio, pois o percentual de impostos é pequeno. Se fosse cobrado pelo MercadoPago a transação teria IOF, um percentual maior de impostos, ....

 

A disponibilização da API é para que viabilize a operação de grandes players, que seria hérculeo operar com o front-end, e muito mais passível de fraude por parte de funcionários.

 

Grátis não é.

 

Até mais,

Rodrigo

 

grande rodrigojob,

 

como eu disse não vejo como falha, e sim como indisponibilidade... vamos supor que o ML utilize NodeJS para disponibilizar as APIs (o que é bem plausível para este tipo de serviço), a própria arquitetura do NodeJS é não bloqueante o que pode causar uma inconsistência momentânea

 

concordo com você que nada nessa vida é gratuito e sim, esse custo está embutido na tarifa do vendedor. somente graças as APIs a operação com grandes players é possível e entramos em diversas questões (muito interessantes por sinal) de estratégia do ML em redução de impostos, menor processamento e responsabilidade sobre exigências de ferramentas específicas por parte dos grandes players, etc... mas que não vem ao caso agora

 

o que me deixa indignado é quando um desenvolvedor ou empresa, que lucra com as APIs (que para ele são gratuitas), não quer investir em infra-estrutura e ainda aponta a falha como sendo exclusivamente de terceiros (Correios, ML, etc) ... disponibilidade 100% é utópico, o ML poderia sim melhorar vários pontos, mas vamos trabalhar com o que temos

 

abraços!!!

Share this post


Link to post
Share on other sites
  • 0

grande rodrigojob,

 

como eu disse não vejo como falha, e sim como indisponibilidade... vamos supor que o ML utilize NodeJS para disponibilizar as APIs (o que é bem plausível para este tipo de serviço), a própria arquitetura do NodeJS é não bloqueante o que pode causar uma inconsistência momentânea

 

concordo com você que nada nessa vida é gratuito e sim, esse custo está embutido na tarifa do vendedor. somente graças as APIs a operação com grandes players é possível e entramos em diversas questões (muito interessantes por sinal) de estratégia do ML em redução de impostos, menor processamento e responsabilidade sobre exigências de ferramentas específicas por parte dos grandes players, etc... mas que não vem ao caso agora

 

o que me deixa indignado é quando um desenvolvedor ou empresa, que lucra com as APIs (que para ele são gratuitas), não quer investir em infra-estrutura e ainda aponta a falha como sendo exclusivamente de terceiros (Correios, ML, etc) ... disponibilidade 100% é utópico, o ML poderia sim melhorar vários pontos, mas vamos trabalhar com o que temos

 

abraços!!!

não tem triplo like?!?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this