В JetBrains Marketplace завели отчёты о подвисаниях интерфейса

В JetBrains Marketplace завели отчёты о подвисаниях интерфейса. Фото: из архива компании

Инженер Якуб Хржановский в корпоративном блоге JetBrains описывает знакомую каждому разработчику ловушку: «пользователь жалуется, что IDE замерла, виновником назначают ваш плагин, вы повторяете те же шаги — и всё идёт как по маслу, а без снятого в момент ступора дампа потоков непонятно, за что вообще браться».

Одна оговорка: прежде чем отчёты начнут приходить, требуется включить отчётность Marketplace внутри самого плагина. Автор рассчитывает, что вкладка так и останется пустой, но советует всё подготовить заранее — до того, как она реально понадобится.

Отчёты на площадке раскладываются по типам ошибок, а похожие случаи складываются в группы, и каждая группа несёт один показательный отчёт — так повторяющиеся паттерны видны без перебора всех инцидентов поштучно.

Автоматически нарезанный фрагмент дампа потоков служит точкой входа: в нём видны потоки, замешанные в зависании, и он же неплохо подходит как первая подача для кодинг-агента — короткий кусок сориентирует модель дешевле по токенам, чем полный дамп.

Копать глубже помогает навык анализа зависаний, после которого имеет смысл подгрузить полные дампы, чтобы агент протянул связи между потоками и сопрограммами. Файлы dump-N.txt — это полные дампы потоков, снимаемые раз в пять секунд на протяжении ступора, а в зависимости от того, что успела зафиксировать IDE, в отчёт могут попасть snapshot.jfr со снимком состояния процессора, report.txt с разбором захваченных стеков и open-telemetry-metrics.csv с метриками производительности, включая активность VFS и отзывчивость интерфейса.

Начинать разумно с единственного отчёта: открыть его и отыскать во фрагменте поток обработки событий, который обычно зовётся AWT-EventQueue-0 или содержит пометку EDT, после чего проверить, не занят ли он тяжёлой работой и не ждёт ли чего-то.

Для более серьёзного разбирательства нужно скачать полный дамп и через «Поиск везде» вызвать «Анализ трассировки стека» либо «Дамп потоков», вставить туда текст и просмотреть выдачу, а разбираясь, что именно тормозит продвижение EDT, сверяться с исходными данными потока. Когда дампов несколько, их сопоставляют между собой, чтобы понять, кочует ли одна и та же операция по стеку от выборки к выборке.

В примере анализатор ловит файловый ввод-вывод на EDT внутри org.xml.sax.helpers.XMLFilterImpl.parse. Виновник, впрочем, может прятаться и в фоновом потоке: затянувшееся неотменяемое чтение удерживает блокировку, нужную записи, и интерфейс простаивает, хотя тяжёлая работа идёт в стороне — этот сюжет разобран в статье о зависаниях интерфейса и опасностях неотменяемых чтений в фоне.

Патрик Шайбе, коллега автора, собрал навык analyze-freeze, который помогает ИИ-агентам разбирать дампы потоков платформы IntelliJ: внутри — подсказки по поведению сопрограмм, «голоданию» Dispatchers.Default и прочим типовым сценариям подвисания вместе с рецептами их лечения.

Чтобы опробовать, нужно сохранить содержимое SKILL.md рядом с материалами расследования, доложить туда полные дампы потоков и, если есть, текст дампа сопрограмм, а затем попросить агента прочесть описание навыка и прогнать файлы по такой подсказке: применить инструкции analyze-freeze к дампам IntelliJ, стартовать с EDT и выяснить, что мешает ему двигаться, определить релевантный участок кода, задействованные потоки или сопрограммы, службы и вероятный плагин, подкрепить каждый вывод убедительными доказательствами, отделяя наблюдаемые факты от гипотез, назвать недостающие доказательства и предложить минимальную правку со способом проверки, не трогая код.

Прежде чем отдавать дампы сервису искусственного интеллекта, стоит соблюсти принятый в проекте порядок обращения с диагностическими данными, а пояснения агента воспринимать как ориентир — сопоставляя указанные кадры с полным дампом и собственным кодом ещё до правок.

Чтобы заработала встроенная отчётность Marketplace, в plugin.xml регистрируют обработчик ошибок — расширение errorHandler с реализацией com.intellij.diagnostic.JetBrainsMarketplaceErrorReportSubmitter. Он доступен с IntelliJ Platform 2023.3 и не требует собственной реализации, а для плагинов с разделением экрана его прописывают во фронтенде или в модуле общего плагина, поскольку регистрация только на бэкенде фронтенду ничего не даст.

Пользователи шлют отчёты через интерфейс IDE для сообщений об ошибках либо включают автоматическую фоновую отправку в JetBrains; если вкладка «Зависания» пустует, первым делом проверяют регистрацию обработчика, ведь отчёты зависят и от пользовательских настроек, и от того, счёл ли IDE плагин причастным.

Тем, кто держит собственную систему отчётности, руководство по отчётам об ошибках SDK расскажет про пользовательский API ErrorReportSubmitter и экспериментальный ErrorReportSink для автоматических фоновых отправок, но для встроенной настройки Marketplace свой приёмник не нужен. Подробнее — в видеообзоре Патрика Шайбе о том, как на самом деле устроена отчётность по ошибкам плагинов IntelliJ: там же разбирается, что именно уходит на сервер и почему вложения критичны для отчётов о подвисаниях.

Прежде чем выбирать решение, проверяют доказательства: перед сопоставлением дампа с кодом уточняют, к какой версии плагина он относится. Версия есть не всегда, а без неё трудно понять, какая сборка пострадала, и деобфусцировать трассировку, поэтому при отсутствии данных её честнее пометить как неизвестную, чем записывать отчёт в актив последней версии. Нащупав вероятную причину, фокусируются на операции, которая блокирует продвижение интерфейса: для долгого фонового чтения это может означать урезание времени доступа к модели или переход на API для отменяемых чтений, при этом ввод-вывод по-прежнему блокируется вне процесса чтения, а вычисления, допускающие перезапуск, должны безопасно повторяться.

Проверка изменений — повторение той же операции и свежие диагностические данные; если проблему не закрыть, задают вопрос на форуме платформы JetBrains, приложив сборку IDE, версию плагина при наличии, нужные дампы и список уже проделанного.

Даже когда зависание не воспроизводится, полные дампы показывают, чем занимались потоки IDE в момент задержки, и дают зацепку для расследования; при включённой отчётности Marketplace стоит наведаться на вкладку «Зависания» — краткие выдержки подскажут, откуда начать.