← Назад к заметкам

Заметки

Почему роботы зависли после обновления модуля

Почему роботы зависли после обновления модуля: диагностика очереди, агентов, workflow, логов.

После обновления проблема может быть не в роботе, а в очереди, агенте, PHP-ошибке или зависшем workflow.

Задача

Сначала нужно отделить бизнес-сценарий от технического механизма.

Задача — почему роботы зависли после обновления модуля. В этой теме важны: Диагностика очереди, агентов, workflow, логов.

Перед правкой лучше воспроизвести сценарий на тестовой карточке и записать фактические ID, типы полей, пользователя запуска и текст ошибки.

Как это устроено

Большинство ошибок появляется из-за неверного формата данных или точки запуска.

  • проверьте агенты и cron;
  • проверьте логи PHP;
  • создайте новый тестовый элемент;
  • сравните старые зависшие процессы и новые запуски;
  • не прерывайте массово workflow без понимания последствий.

Рабочий подход

Начинайте со штатного API и добавляйте обходы только там, где штатный сценарий не покрывает задачу.

Для облака используйте REST и проверяйте права приложения. Для коробки, если код выполняется внутри портала, чаще удобнее PHP/D7 и штатные классы модуля.

Если действие меняет CRM-карточку, учитывайте роботов, бизнес-процессы, события и повторные вызовы обработчиков. Любая запись в карточку может стать новым триггером.

Частые ошибки

Ошибки лучше ловить на минимальном примере, а не в большом процессе.

  • не проверили права пользователя или приложения;
  • перепутали ID, текстовое значение и XML_ID;
  • передали строку вместо массива для множественного поля;
  • запустили процесс повторно и получили дубли;
  • обошли штатную операцию CRM и не запустили роботов или события.