Зависший npm install и DSH: чему учит публичный сбой в цепочке зависимостей DeepSeek

Свежий повод: зависание до старта интерфейса, а не сбой модели

21 августа 2026 года в GitHub Discussions репозитория DeepSeek Harness появился отчёт о проблеме при запуске команды npx @deepseek-ai/dsh web. По наблюдениям участников обсуждения, интерфейс не успевал запуститься и не обращался к модели: процесс зависал на установке пакетов.

В репорте описана среда Windows 11 с Node 24 и npm 11. После получения метаданных заметная сетевая активность прекращалась, лог останавливался около операции placeDep, процесс удерживал одно ядро CPU и продолжал потреблять память. Порт 127.0.0.1:3080 при этом не начинал принимать соединения.

Это важное разграничение для расследования. Имеющиеся данные не указывают на ошибку модели DeepSeek, токенизации, API-ключа, GPU-вычислений или inference-рантайма. Речь идёт о предзапусковом этапе поставки, когда npm читает манифесты, подбирает совместимые версии, строит дерево зависимостей, при необходимости создаёт lockfile и раскладывает пакеты.

На момент обсуждения не было публичного root cause analysis, исправленного релиза или подтверждённого патча. Поэтому называть случай подтверждённым бесконечным циклом в npm или DSH нельзя. Симптом может быть следствием крайне медленной ветвящейся процедуры разрешения, а не цикла в исходном коде.

В комментарии от 23 августа участник Discussion #3786 представил минимизированный A/B-тест для @deepseek-ai/dsh-web-app@0.1.1-rc.2. В четырёх комбинациях Node 22.22.2 или 24.19.0 с npm 10.9.2 или 11.17.0 полная установка не завершилась за 45 секунд. Это ослабляет гипотезы о проблеме только npm 11 или только Node 24, но не устанавливает единую причину для всех сред.

DeepSeek характеризует Harness как developer preview и предупреждает о быстрых итерациях и возможных несовместимых изменениях. Такой статус не запрещает эксперименты, однако для общего стенда или CI требует точных версий, чистых окружений, проверяемого lockfile, лимитов на установку и заранее подготовленного отката.

• Подтверждён публичный отчёт и наблюдаемый симптом: зависание происходит во время установки.
• Не подтверждено, что в npm или DSH обнаружен именно бесконечный цикл.
• Не доказано, что эффект одинаково воспроизводится на Linux, macOS, за корпоративными прокси, с разными кэшами и lockfile.

Цитата в переводе

«Спасибо за сообщение о проблеме и помощь в расследовании; мы займёмся проверкой.»

Цитата в переводе

«Добавляю набор минимизированных и контролируемых A/B-доказательств для 0.1.1-rc.2; Windows 11, все зависшие деревья процессов остановлены.»

Почему peerDependencies оказываются в центре расследования

Обычная dependency означает, что пакет нужен приложению во время работы и должен поставляться вместе с ним. Peer dependency устроена иначе: библиотека предполагает, что совместимую версию нужного пакета предоставят выше по дереву зависимостей. Это удобно для плагинов и расширений, которым нужен общий экземпляр фреймворка, но усложняет согласование версий в плотном графе.

В документации DeepSeek Harness межпакетные связи семейства @deepseek-ai/dsh-* описаны через peerDependencies, названные каноническим сигналом runtime-зависимостей. В коде загрузчика профилей peers также участвуют в обходе графа при fallback-разрешении модулей: внешний плагин может напрямую импортировать пакет с описанием сервисов. Значит, peer-метаданные важны и при установке, и при поиске модулей после неё.

npm строит ideal tree, то есть расчётное дерево пакетов до фактической раскладки в node_modules. Документация Arborist объясняет, что при обработке зависимости npm загружает её манифест, рассматривает peerDependencies и старается разместить пакет в максимально высоком допустимом месте дерева. Обработка peers может потребовать повторно пройти связанную часть графа; отдельно упомянуты сложности циклов peer-зависимостей.

Для DSH отсюда следует инженерная гипотеза, но не установленный диагноз. Большое число внутренних пакетов, перекрёстные peer-связи, широкие диапазоны предварительных версий и неполностью синхронные публикации одного семейства способны сильнее нагружать resolver, чем плоский набор runtime-зависимостей. Публичных CPU-профилей Arborist или анализа графа, которые подтвердили бы конкретный цикл, в досье нет.

• Проверять нужно не только корневой @deepseek-ai/dsh, но и фактически выбранные версии внутренних @deepseek-ai/dsh-*.
• Peer dependency не равна опциональной зависимости: её отсутствие способно проявиться ошибкой уже после успешной установки.
• Широкий semver-диапазон в preview-линейке повышает значение lockfile и воспроизводимого разрешения версий.

Что показали обходы и почему их нельзя считать исправлением

Один из показательных результатов Discussion #3786 связан с флагом --legacy-peer-deps. В описанном A/B-тесте его добавление позволило завершить установку @deepseek-ai/dsh@0.1.0-rc.6 примерно за 25 секунд. Это сильный сигнал, что современная ветка обработки peerDependencies имеет значение, но сам флаг меняет правила разрешения шире одной внутренней операции npm и не доказывает конкретную первопричину.

Обход дал двойственный результат. Участники обсуждения сообщали, что после установки с ослабленным peer-resolution DSH мог завершиться ошибкой ERR_MODULE_NOT_FOUND. Нужные пакеты оставались объявленными только как peers и не оказывались доступными там, где их ожидал ранний boot-путь. Для production замена install-time failure на runtime failure особенно рискованна: CI формально проходит, а сервис ломается при запуске.

Отдельный пользовательский репорт от 14 августа тематически усиливает этот риск. В Discussion #1032 автор утверждал, что @deepseek-ai/dsh-app-boot статически импортирует @deepseek-ai/cordis-plugin-group, а опубликованный манифест относит его к peerDependency, а не к обычной runtime dependency. В чистой среде это связывалось с ERR_MODULE_NOT_FOUND. Это не подтверждённый вывод DeepSeek, а сигнал о другом типе отказа в той же supply-chain-зоне.

В Discussion #3786 также упоминается успешный опыт с pnpm dlx. Его разумно использовать как диагностический вариант: другой менеджер пакетов может иначе обработать граф и помочь отделить проблему конкретного пути npm от проблем манифестов. Публичной инструкции DeepSeek, закрепляющей pnpm как поддерживаемую замену npm для этих релизов, нет. Перенос обхода в корпоративный pipeline без проверки прокси, кэшей, лицензий и структуры node_modules преждевременен.

• Используйте --legacy-peer-deps для контролируемой локализации, а не как автоматический production-фикс.
• Успешная установка сама по себе не подтверждает корректную поставку runtime-зависимостей.
• Смена package manager может сузить область поиска, но не отменяет проверки запуска и health check.

Как локализовать проблему в стенде за один диагностический цикл

Распространённая ошибка состоит в том, чтобы оставить npx @deepseek-ai/dsh web единственным тестом. Эта команда объединяет получение манифестов, расчёт дерева, скачивание и распаковку пакетов, lifecycle scripts, запуск бинарника и инициализацию веб-приложения. В результате команда видит только итоговое «не поднялось», хотя на каждом этапе нужны отдельные гипотезы и артефакты.

Первый прогон стоит отделить от запуска приложения. Для этого в npm install указывают точную версию @deepseek-ai/dsh, включают создание только package-lock, отключают scripts, audit и fund, а также используют verbose-логи и timing. Такой тест отвечает на наблюдаемый вопрос: появился ли lockfile за ограниченное время. Отключение scripts не устраняет проблему resolver, но убирает из первого опыта install hooks и их побочные эффекты.

Далее нужен жёсткий timeout вместо неограниченного ожидания. По его достижении CI должен завершить дерево процессов и сохранить node --version, npm --version, package.json, lockfile или факт его отсутствия, .npmrc, verbose- и timing-логи. Полезно добавить CPU, пиковый RSS процесса и в изолированных средах сведения о сетевых соединениях за последние секунды.

Такой набор помогает отличить проблемы DNS, TLS, proxy или registry от тяжёлой работы в idealTree или placeDep. В публичном репорте смена npm registry, по утверждению автора, не сняла симптом, а запросы до остановки процесса возвращали HTTP 200. Это не повод исключать сеть из диагностики, особенно в инфраструктуре с прокси, но и не основание назначать её причиной без артефактов.

Целевой пакет нужно сравнивать с контрольными. В комментарии от 23 августа dsh-web-app выделен как более вероятная проблемная часть опубликованного графа, тогда как dsh-app-boot, dsh-headless и dsh-base в тесте автора завершались примерно за 1,3–16,2 секунды. Эти цифры относятся к пользовательской среде Windows 11, а не к тестированию редакции. Однако методика полезна: менять по одной переменной и искать подграф, с которого начинается деградация.

• Запускайте resolution в свежем контейнере или на чистом runner, а не только на машине с тёплым кэшем.
• Разделяйте install, запуск DSH и проверку готовности интерфейса либо headless-профиля.
• Фиксируйте корневой пакет, версии Node и npm, а также содержимое lockfile как единый набор воспроизводимости.

Цитата в переводе

«Тем самым проблему можно сузить от полного CLI до опубликованного графа зависимостей Web bundle.»

Версионная гигиена: где искать расхождение

Для DSH недостаточно формулировки «ставим DeepSeek Harness». В публичных тестах фигурируют 0.1.0-rc.6, 0.1.0-rc.7 и 0.1.1-rc.2. Суффикс rc обозначает предварительную ветку, где новая версия способна менять не только код, но и состав, а также совместимость пакетов. Плавающий latest в production pipeline делает расследование почти бессмысленным: сегодня CI соберёт одно дерево, завтра другое.

Практический аудит начинается с @deepseek-ai/dsh, но им не заканчивается. Нужны фактически разрешённые версии @deepseek-ai/dsh-web-app и других внутренних пакетов, диапазоны peerDependencies, их пересечения, а также статус peerDependenciesMeta. Если peer действительно необязателен, это должно быть явно отражено в метаданных. Если модуль статически импортируется на критическом boot-пути, поставка обязана гарантировать его наличие в среде исполнения.

Полезно отдельно проверять dist-tags и не считать их контрактом воспроизводимости. Тег удобен для ручного знакомства, но для стенда важнее точная версия с lockfile, созданным и проверенным в согласованной паре Node и npm. Обновление lockfile, затрагивающее внутреннее семейство DSH, следует рассматривать как полноценное изменение поставки, а не как рутинное обновление одной библиотеки.

Документация npm описывает packageExtensions: корневой проект может декларативно добавить недостающее dependency-ребро или исправить peer metadata до появления upstream-фикса. npm называет механизм временным способом работы со сломанными манифестами; изменение фиксируется в lockfile. Это предпочтительнее ручной правки node_modules, но применять подход следует только после воспроизводимого подтверждения, проверки лицензий и security review. У такого исправления должны быть владелец, срок пересмотра и тест реального запуска.

• Требуйте точные версии вместо плавающих тегов в CI и стендах.
• Аудируйте peerDependencies, peerDependenciesMeta, dependencies, dist-tags и итоговый lockfile.
• Оформляйте каждое временное исправление манифеста как технический долг с условием удаления.

План отката важнее удачного первого запуска

Production-интеграция preview-инструмента начинается с вопроса, что произойдёт, если новая версия перестанет собираться в понедельник утром. Нужна известная рабочая сборка: контейнерный образ или внутренний артефакт с уже проверенной комбинацией DSH, Node, package manager и lockfile. Это не отменяет обновления, а переводит их из случайного скачивания в управляемое изменение.

В pipeline нужны два независимых барьера. Первый проверяет разрешение зависимостей в чистом окружении и ограничивает wall time, CPU и память. Второй запускает установленный DSH и выполняет health check нужного интерфейса или headless-профиля. Если не проходит первый барьер, новая сборка не должна тратить ресурсы на дальнейшие этапы. Если не проходит второй, команда видит риск неполной runtime-поставки, а не получает ложное подтверждение, что npm отработал.

Условия отката следует определить заранее. Ими могут быть отсутствие lockfile к дедлайну, рост RSS выше лимита, несоответствие разрешённых версий утверждённой матрице или ошибка импорта при холодном запуске. В каждом случае лучше вернуть предыдущий закреплённый артефакт и открыть воспроизводимый инцидент для поставщика или внутренней платформенной команды, а не подбирать случайные флаги в боевой ветке.

• Храните последний проверенный образ или артефакт как штатный путь отката.
• Ограничивайте install job по времени, CPU и памяти, иначе solver способен занять runner без результата.
• Проверяйте cold start после установки: lockfile не заменяет запуск.

Что этот случай говорит поставщику и потребителю

Публичный инцидент даёт DeepSeek основание укреплять не только код DSH, но и практику публикации пакетов. Это редакционная рекомендация, а не объявленный план компании: проверять опубликованные tarball в отдельном CI, а не ограничиваться тестами внутри монорепозитория. Такой smoke test должен моделировать чистую среду, фиксировать поддерживаемые Node и npm, выполнять расчёт lockfile, измерять время и память, затем запускать минимальный профиль.

Не менее полезны машинно читаемый граф зависимостей и проверки на циклы, чрезмерно широкие peer-диапазоны и рассинхронизацию релизов @deepseek-ai/dsh-*. Для ранних boot-зависимостей стоит автоматически сопоставлять статические импорты с declared dependencies либо с гарантированной схемой установки peers. Документация и исходный код DSH показывают, что peer-граф является частью архитектуры и должен контролироваться как runtime-контракт.

Потребителю не стоит превращать preview-инструмент в незаметную критическую зависимость. Developer preview не означает запрета на использование, но требует изоляции обновлений, наблюдаемости и возможности возврата. Публичный статус DSH прямо предупреждает о быстрых итерациях и compatibility-breaking changes.

Исторический контекст позволяет не драматизировать кейс, но и не игнорировать его. В npm/cli ранее фиксировался отдельный случай зависания, связанный с циклическими file:-зависимостями. Это показывает, что деградация package solver возможна как класс инцидентов. Старый баг не доказывает цикл в графе DSH и не подтверждает связь с нынешним репортом.

• Факт: DeepSeek отреагировал на публичный отчёт, но в доступном досье нет публичного RCA или объявления об исправлении.
• Поставщику стоит ожидать прозрачного статуса затронутых релизов, матрицы поддержки и проверенного workaround: это редакционная рекомендация.
• По мере переноса агентских инструментов из экспериментов в стенды supply-chain-проверка будет становиться такой же обязательной, как health check модели. Это авторская интерпретация кейса.

Что это означает на практике

Главный урок кейса не в том, что у DeepSeek или npm доказан бесконечный цикл. Он в другом: зависимость способна сорвать внедрение ИИ-инструмента ещё до первой генерации токена, если команда не контролирует слой разрешения пакетов.

Зрелость в этой зоне измеряется не количеством удачных запусков на ноутбуке. Она определяется тем, можно ли воспроизвести установку в чистом окружении, понять причину сбоя по артефактам, не потратить впустую ресурсы CI и за минуты вернуться к известной рабочей сборке. Для developer preview это минимальная инженерная гигиена.

• Закрепляйте точную версию @deepseek-ai/dsh, Node и npm; храните lockfile как часть поставляемого артефакта.
• Разделяйте в CI расчёт dependency tree, фактическую установку и запуск DSH с health check.
• При зависании собирайте verbose- и timing-логи, версии инструментов, CPU, RSS и сведения о создании lockfile.
• Используйте --legacy-peer-deps только как диагностический эксперимент; после него проверяйте холодный запуск и отсутствие ERR_MODULE_NOT_FOUND.
• Поддерживайте готовый к откату образ или внутренний артефакт с последней проверенной комбинацией DSH и зависимостей.
• Если временно используете packageExtensions, фиксируйте изменение в lockfile, проводите security review и назначайте срок удаления workaround.

Диагностический чек-лист для DSH в CI

Сохраните этот список как рабочую памятку для первого цикла расследования. Он не заменяет анализ опубликованных манифестов и не предполагает, что причина случая уже установлена.

Изоляция установки

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

• Запускайте тест в чистом контейнере или на чистом runner.
• Фиксируйте точные версии DSH, Node и npm.
• Проверяйте появление lockfile в пределах заданного timeout.
• Отключайте побочные задачи npm в первом диагностическом прогоне, чтобы отделить resolver от scripts.

Артефакты инцидента

Артефакты должны позволять повторить проблему и отделить работу resolver от проблем сети или окружения.

• Сохраняйте package.json, lockfile либо факт его отсутствия и .npmrc.
• Сохраняйте verbose- и timing-логи npm.
• Записывайте версии Node и npm, CPU, пиковый RSS и длительность процесса.
• При изолированном запуске сохраняйте сведения о сетевых соединениях перед timeout.

Проверка результата и откат

Завершившийся install не является финальным критерием. Нужен холодный запуск и health check выбранного интерфейса или headless-профиля.

• Не принимайте --legacy-peer-deps за production-исправление без проверки runtime.
• Проверяйте ERR_MODULE_NOT_FOUND после установки.
• Сравнивайте разрешённые внутренние DSH-пакеты с утверждённой матрицей.
• При нарушении лимитов возвращайте предыдущий проверенный артефакт.
• Назначайте владельца и срок пересмотра для временного workaround.

Источники

• DeepSeek Harness Discussion #3786: npm install @deepseek-ai/dsh hangs in infinite CPU loop
• npm Arborist: ideal tree
• DeepSeek Harness: module graph
• DeepSeek Harness: profile loader source
• npm package.json documentation
• DeepSeek Harness repository
• DeepSeek Harness Discussion #1032
• npm/cli issue #1600

Практический чек-лист

Чек-лист диагностики DSH в CI

PDF-файл должен повторять практический чек-лист статьи в удобном для сохранения и печати виде.

Изоляция установки

• Запустите тест в чистом контейнере или на чистом runner.
• Зафиксируйте точные версии DSH, Node и npm.
• Проверьте создание lockfile в пределах заданного timeout.
• Отделите resolver от scripts в первом диагностическом прогоне.

Артефакты инцидента

• Сохраните package.json, lockfile либо факт его отсутствия и .npmrc.
• Сохраните verbose- и timing-логи npm.
• Запишите CPU, пиковый RSS и длительность процесса.
• При необходимости сохраните сведения о сетевых соединениях перед timeout.

Проверка и откат

• Проверьте cold start и health check после установки.
• Не считайте --legacy-peer-deps готовым исправлением без runtime-проверки.
• Сравните разрешённые версии пакетов с утверждённой матрицей.
• При нарушении лимитов верните предыдущий проверенный артефакт.