Получить Lead time distribution Report или фильтровать activityItem по типу / значению
Добрый день!
Используем YT Standalone 2022.1.46592.
Стоит задача получить виджет, показывающий Lead time distribution (распределение задач по время перехода из одного состояния в другое). Поскольку такого отчета нет, пытаюсь получить измнения состояний задач через
/api/activities
и
/api/activitiesPage
В обоих случаях YouTrack не может вернуть весь набор данных, хоть постранично, хоть все сразу: при достижении времени обработки запроса 5 минут возвращается ответ
{"error":"server_error","error_description":"Обработка занимает слишком много времени :("}
При этом время выполнения запроса /api/activitiesPage в случае растет с каждым запросом (скриншот),
а в /api/activities зависит от номера п/п получаемых элементов - при $top=1000&$skip=0 время 0.5с, при $top=20000&$skip=0 - 5 минут, при $skip=19900&$top=100 - те же 5 минут.
Фильтра activityItem по типу полей тоже нет (или я не нашел - параметр query никак не меняет результат).
Возможно, есть фильтрация activityItem по полю field.id или field.customField.(id | name)?
Подскажите пожалуйста, как правильно решать такую задачу.
Please sign in to leave a comment.
Здравствуйте.
Спасибо за сообщение. Давайте разбираться.
Для начала пару базовых моментов. 5 минут — стандартный таймаут, который дается на выполнение REST API операций на YouTrack Server.
query
параметр предназначен в основном для/issues
эндпоинта, а не для/activities
(или/activitiesPage
). Для activities вы можете передать поля, которые вас интересуют, дальше уже фильтровать нужно данные из полученного результата.Стандартная пагинация для большинства REST API эндпоинтов — 42, поэтому ожидать, что пройдет $top=20000, не всегда реалистично. Плюс сильно зависит от того, сколько полей вы запрашиваете. Если условно один ID, то намного больше данных можно вернуть. Если вы включили все поля, которые нашли, то возможно какой-то ивент возвращает слишком много данных.
Тут советую попробовать следующие:
поэкспериментировать с пагинацией и с полями, использую реалистичные значения
если у вас запрос падает по таймауту даже со стандартной пагинацией, то пришлите сам запрос и скриншот c <your YouTrack URL>/admin/statistics во время выполнения запроса. Возможно, это результат плохой работы самого сервера.
Так как это публичный форум, вы можете прислать данные напрямую в поддержку через https://youtrack-support.jetbrains.com/hc/en-us/requests/new или youtrack-support@jetbrains.com.
Добрый день, Сергей!
Спасибо за быстрый ответ, давайте продолжим общение здесь, т.к. конфиденциальных данных нет, а, возможно, обсуждение будет полезно еще кому-нибудь.
Отправляем вот такие запросы ($top специально сделал маленьким, чтобы подчеркнуть, что дело не в размере возвращаемых данных):
Меняем $skip (50000, 70000), получаем такую картину:
Скриншот /admin/statistics при выполнении последнего запроса:
Решил проблему, реализовав "постраничную" загрузку через определение параметров start и end. В таком исполнении время ответа зависит только от размера возвращаемых данных.
Видимо, проблема увеличения времени ответа при постраничной загрузе через /activityPage и невлияние на время ответа параметра $skip в /activities это недоработка.
Добрый день.
Спасибо за детали.
Изучили детально работу эндпоинтов. Вы правы. Есть проблема с использованием пагинации с большим количеством прыжков. Будем дальше разбираться в рамках этой задачи: https://youtrack.jetbrains.com/issue/JT-70016/Pagination-doesnt-work-reliably-with-activities-and-inbox-endpoints
Обходное надежное решение как раз использовать start и end, как вы и сделали.
Также в целом /activityPage использовать вместо /activities смысла нет. /activityPage больше подходит для использования на фронтэнде.
Если будут вопросы, то, пожалуйста, дайте знать.
Добрый день, Сергей!
Спасибо за пояснения и помощь, обязательно буду сообщать о проблемах, если таковые встретятся.
Вам спасибо! Если что — можете писать нам напрямую через https://youtrack-support.jetbrains.com/hc/en-us/requests/new или youtrack-support@jetbrains.com.