backgroundbackground
Назад
Назад

/api/v3/orders?limit=1000 выдает 1001, дублируя одно из заданий

Обсуждение
3
7226
# Заказы FBS
Обсуждение

Собственно, сабж. Сценарий следующий: 1. Беру сборку, получаю сборочные задания для нее (/api/marketplace/v3/supplies/{supplyId}/order-ids) - получаю 1111 штук. 2. Начинаю опрашивать /api/v3/orders?limit=1000&next=${next}&dateFrom=${dateFrom} начиная с последних 3х дней. Листая next и сохраняя результат для требуемых id сборочных заданий. 3. Если количество полученных в п2 сборочных заданий не равно требуемому количеству - увеличиваю интервал - 10 дней, потом 30 дней и тд.

И в какой-то момент /api/v3/orders?limit=1000&next=${next} - начинает выдавать 1001 штуку, дублируя одно из заданий 2 раза. В итоге, пролистав странички, получается 1112 штук, тк дублируемый заказ входит в запрашиваемое множество IDs.

Соответственно, количество полученных заданий (1112) не равно количеству запрашиваемых (1111). Сотрудники тыкают кнопки, а мы гоняем по кругу API до времен динозавров и никак не можем получить требуемое количество заказов.

Фикс - нужно фильтровать полученные из этого эндпоинта /api/v3/orders результаты по ID, чтобы добиться их уникальности.

Это баг или фича?

+3
Комментарий

Тоже столкнулся с такой проблемой сегодня.

1. Беру сборочные задания с лимитом 100 а выдает 101.

2. Получаю следующую страницу, и первой строкой тот заказ, который был последним в пункте 1. При этом next выдает значение меньше, чем next в пункте 1, причем стабильно next=946 674 000 000 000 000.

Судя по моим логам такое поведение появилось только сегодня.

+1

Ответы на комментарий

У меня тоже проблема не сразу проявилась. Во время тестирования и пуско наладки новых методов АПИ все было нормально - ставишь лимит 1000 - получаешь не более 1000, а 23го заметил что барахлит. Причем не везде, а при каких-то условиях это происходит. Проблема явно в реализации API

0

Доброго дня, у меня тоже самое, Параметр пагинации у последней позиции 946 674 000 000 000 000, и неважно, каков лимит и количество заказов

+1
Комментарий

Аналогичное поведение с апи, первые дни работало нормально, в последние дни работает с ошибкой, при то том что ошибка со временем исчзает, и появляется снова с одной поставкой

+1
Комментарий

Вообще, проблема приобретает достаточно острый характер. Так как судя по всему, заключается она не только в дублировании ордеров в выдаче, но и в отсутствии каких то ордеров, или каких то еще косяках выдачи, так как есть сборки, заказы в которых просто отсутствуют в выдаче. Да и сама выдача работает криво. Делаю запрос ордеров за последние 3 дня - получаю 2 вхождения из нужных 3. Делаю запрос за 10 дней - получаю 0 ордеров нужных, делаю за 30 дней - 0 ордеров нужных. При том, что среднее время жизни заказа до отгрузки ну типо 35 часов.

Далее, пытаясь понять что ж это за чертовщина - гоняю по кругу эти запросы и на 10й раз первый запрос (за 3 дня который) все таки возвращает нужные ордера. Повторяю его - и снова ордеров нет. Явно разрабы где то накосячили, с датой и/или пагинацией. Пока непонятно что с этом делать.

0
Комментарий

Видимо баг исправлять не собираются, а может не могут воспроизвести... Как альтернатива - было бы здорово иметь параметр отвечающий за сортировку заказов по дате в /api/v3/orders от новых к старым, это существенно сократило бы количество запросов к АПИ и, вероятно, сняло бы часть претензий к неправильно работающей пагинации.

0

Ответы на комментарий

Ну ёк макарёк, вот опять - производство стало потому что из 21 задания в сборке выдается только 20 из заказов, сколько их не пагинируй. Я так понял разрабы не могут воспроизвести проблему, тк она по сути плавающая и проявляется при определенных (не установленных пока) условиях, но это чертовски нарушает производственные процессы.

0