Ожидание новой заявки ST_REQUEST: обработчик и очередь
Область: ShariX Open. Основание: реализация обработчика open_st_request_new и планировщика очереди, проверенная 28.10.2026 по указанным ниже версиям Git. Это описание реализованного механизма ожидания, а не проект будущего процесса.
Назначение и границы
Процесс начинается, когда Ticket уже передан обработчику open_st_request_new. Он показывает, как обработчик проверяет свой рабочий статус, фиксирует причину ожидания и передаёт повторную проверку планировщику. Две дорожки обозначают программные компоненты: обработчик и планировщик его очереди. Действия заявителя или сотрудника сюда не включены: из значения support_assignment нельзя вывести полный сценарий ручного согласования.
BPMN используется для описания. Просмотр схемы в Wiki не запускает обработчик и не создаёт таймер. В XML установлен isExecutable=false; scheduled_recheck_at — условное обозначение вычисленного срока, а не имя настройки установки.
Обработчик получает Ticket и проверяет соответствие статусу NEW, указанному в его workspace.
Если статус соответствует, обработчик записывает локальную причину ожидания support_assignment и назначает повторную проверку через ST_REQUEST_NEW_RECHECK_SECONDS. Число секунд берётся из действующей конфигурации handlers; по одной схеме его определить нельзя. Реализация требует положительное целое значение, минимум одна секунда.
Текущий проход обработчика завершается. Отложенный Ticket не занимает рабочий поток ожиданием; очередь может обрабатывать другие готовые элементы.
При наступлении срока планировщик снимает отсрочку и возвращает Ticket в готовую очередь. Следующий проход снова проверяет статус. Истечение таймера означает готовность к запуску, а не гарантию запуска в ту же секунду: учитываются доступные workers и готовность XMPP.
Распознанное внешнее событие может сделать Ticket готовым раньше срока. Например, request_ticket_ready снимает локальную отсрочку и будит планировщик. События обновления Ticket обрабатываются с получением актуального состояния из backend. После пробуждения заново проверяется статус, решение прежнего прохода не считается вечным.
Если Ticket дошёл до проверки обработчика уже с другим статусом, ветка ELSE убирает его из локальной очереди и запрашивает удаление комнаты уведомлений. Это прекращение обработки данным обработчиком; оно не означает удаления самого Ticket из backend или завершения всей заявки.
Дополнительные пути runtime
Схема показывает основной цикл одного Ticket. Периодическая сверка очереди с backend также может обновить снимок, снять отсрочку либо исключить Ticket, который больше не входит в область данного обработчика. Поэтому не каждое изменение статуса обязательно дойдёт до ветки ELSE на картинке: runtime может убрать элемент раньше при сверке или событии удаления.
Отсрочка и причина ожидания хранятся в памяти процесса. После перезапуска прежний срок таймера не восстанавливается как сохранённое бизнес-обязательство: очередь загружает актуальные Ticket из backend и оценивает их заново. Не следует использовать этот локальный механизм как доказательство долговечного SLA-таймера или как журнал решений сотрудника.
Ошибки загрузки из backend, повторные события, остановка процесса и исчерпание попыток относятся к общему runtime и не развёрнуты в отдельные ветки этой компактной схемы. Отказ API при сверке не доказывает исчезновения Ticket: runtime сохраняет локальный снимок и пишет диагностику. Эти пути нужно учитывать при поиске неисправности.
Что проверять при диагностике
Соответствует ли Ticket типу и рабочему статусу обработчика; не был ли он исключён из очереди после актуальной сверки backend.
Какое значение ST_REQUEST_NEW_RECHECK_SECONDS действительно настроено у запущенного экземпляра handlers.
Есть ли причина ожидания и локальный срок defer; получал ли планировщик событие, снимающее отсрочку раньше срока.
Есть ли свободный worker и готово ли XMPP-соединение. Готовность Ticket и фактический запуск — разные моменты.
Не перезапускался ли процесс: локальные признаки предыдущего ожидания после этого нельзя считать сохранёнными.
Соответствуют ли установленные workspace и runtime версиям ниже. Схема подтверждает изученный код, но сама по себе не подтверждает состав конкретной работающей установки.
В workspace проверены ветки PROCESS/DO/ELSE и параметры ожидания. В runtime проверены start_handler, promote_due_deferred, request_ticket_ready, defer_ticket_for_setting, defer_ticket_for_seconds, set_waiting_reason и обработка событий/сверки. Git-источники обновлены перед публикацией; актуальные вершины совпали с указанными версиями.
