ScriptRunner Cloud listeners: событие как сигнал, а не готовый снимок всех данных

Чем Cloud отличается от привычного локального обработчика

Администратор переносит listener из Data Center в Cloud и ожидает тот же объект задачи, локальные сервисы Java и немедленное изменение в одном процессе. В Cloud listener реагирует на webhook-событие и работает в другой модели выполнения. Поэтому сначала переносите бизнес-смысл, а затем выбирайте доступные API и контекст. Совпадающий язык отдельного скрипта не означает совместимость объектов и библиотек.

Рассмотрим обновление признака маршрутизации после изменения категории заявки. Событие сообщает о действии, но обработчику может потребоваться актуальное состояние задачи. За время доставки пользователь или другая интеграция уже могли изменить данные. Сразу определите, обрабатываете ли вы состояние на момент события или приводите текущую задачу к состоянию, соответствующему действующей категории. Для фоновой маршрутизации обычно полезна вторая модель, но её нужно согласовать.

Зафиксируйте доступный контекст

В документации установленной версии и в интерфейсе ScriptRunner проверьте переменные выбранного события. Не обращайтесь к предполагаемому полю только потому, что оно было в Data Center. На тестовой задаче выведите безопасные признаки: идентификатор задачи, тип события и наличие нужного значения. Для дополнительного чтения используйте документированный Jira Cloud REST API с нужными разрешениями. Не считайте, что webhook всегда содержит все поля, требуемые бизнес-логикой.

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

Повторная обработка должна быть безопасной

Вычислите нужный маршрут и сравните его с текущим. Если значение уже правильное, запись не нужна. Это защищает от обычных повторов и сокращает количество событий. Учитывайте, что собственное изменение listener может вызвать новое событие; проверка равенства позволяет новой обработке завершиться без очередной записи. Не рассчитывайте только на встроенную защиту от циклов: она ограничивает ущерб, но не заменяет правильную логику.

Если обработка создаёт комментарии, задачи или внешние уведомления, сравнения одного поля недостаточно. Используйте устойчивый идентификатор бизнес-события и состояние доставки, соответствующее требованиям процесса. Для строгой уникальности при параллельных вызовах может понадобиться внешнее устойчивое хранилище. Документируйте возможный частичный результат: Jira обновлена, а внешнее уведомление ещё нет. Эти действия нельзя автоматически считать единой транзакцией.

Ошибки API и ограничения исполнения

Разделяйте отказ авторизации, отсутствие объекта, ограничение частоты и временную недоступность. Повторять некорректный запрос без изменений бессмысленно; для временной ошибки допустим ограниченный повтор через подходящую инфраструктуру. Не создавайте длительную блокирующую петлю внутри listener, рассчитывая дождаться внешней системы. Сверяйте текущие ограничения выполнения и учитывайте, что несколько последовательных медленных запросов быстро расходуют доступное время.

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

Проверка и восстановление

Проверьте обычное изменение, повтор того же события, быстрое изменение категории дважды, отсутствующее поле и отказ прав. Добавьте соседнюю автоматизацию, которая меняет маршрут, чтобы выявить конфликт источников истины. Сравнивайте конечное состояние задачи и число записей в истории. Успешное выполнение скрипта не доказывает, что позднее событие не вернуло устаревшее значение.

При ошибочной массовой маршрутизации отключите listener, сохраните историю и составьте точную выборку затронутых задач. Не включайте исправленную версию одновременно со старой. Восстановите значения адресно, затем выполните контрольную сверку текущих категорий. После запуска следите за повторными событиями и долей обработок без изменения. Хороший listener Cloud устойчив к повтору, не зависит от локальных объектов Data Center и имеет понятное поведение при неполном контексте.

Договорённость о запоздавших изменениях

Обсудите с владельцем процесса сценарий, когда пользователь меняет категорию несколько раз за короткий период. Если задача должна отражать последнее состояние, обработчик проверяет актуальные данные и не пытается восстановить каждое промежуточное значение. Если требуется аудит каждого бизнес-события, нужен отдельный журнал с устойчивыми идентификаторами и порядком. Эти задачи нельзя смешивать случайным набором комментариев. Запишите выбранную модель рядом с listener и включите её в тестовый пример. Такая договорённость позволяет оценивать правильность результата при задержках доставки, не полагаясь на удачный порядок нескольких тестовых запусков.