Это старая версия документа!
Содержание
SERVICE_REQUEST в BOOKED: ожидание исполнителя и окно PENDING
Назначение: Сценарий процесса. Продукт: ShariX Open.
Для кого: Разработчик · Поддержка · Рецензент и приёмщик · Нейросеть.
Темы: Заказы → Назначение · Заказы → Жизненный цикл · Обработчики → Runtime.
Область: ShariX Open. Обработчик: open_service_request_booked, тип SERVICE_REQUEST (2), рабочий статус BOOKED (211). 31.10.2026 опубликованные исходники повторно получены из Git. Обе Python-копии заново сопоставлены с результатом генерации Blockly; проверены 11 исходников генераторов. Сам handler не исполнялся. Выбранную версию, конфигурацию и внешние подключения сервера проверяют отдельно.
Назначение и границы
Handler сопровождает размещённый заказ в таком порядке:
- Попытаться применить одно разрешённое намерение take/cancel.
- Если проход не завершён — загрузить актуальный контекст заказа.
- Проверить окно автоматического перехода в PENDING.
- При отсутствии завершённого перехода назначить повтор.
В BOOKED handler не выбирает кандидатов, не рассылает предложения и не проводит раунд победителя. Это отдельная стадия PENDING.
Условие перехода зависит от заказа:
- ASAP: попытка PENDING сразу после проверки intent и загрузки контекста.
- Плановый заказ: ждать pending_at.
Универсальный autoaccept здесь не используется.
BPMN имеют isExecutable=false. Wiki не исполняет процесс: runtime выполняет выбранный проверенный Python из Blockly. End event завершает показанную операцию; он не означает завершения услуги.
Один проход и ожидание (BPMN)
Чужой статус запрашивает очистку локального Ticket и комнаты. В своём статусе успешный intent либо stale завершают проход. Если намерение не найдено или доменное пользовательское действие отклонено, handler продолжает обычную проверку BOOKED и загружает scoped order context.
После контекста записывается локальная причина awaiting_pending_window. ASAP идёт к move-booked-to-pending без ожидания планового окна. Иначе pending_at сравнивается с текущим временем runtime. Подтверждённый успех/stale исключает Ticket из очереди; обработанный доменный отказ оставляет его для повтора по SERVICE_REQUEST_BOOKED_RECHECK_SECONDS.
Ошибки контекста и action трактуются отдельно:
- 404: устаревший scope, запрашивается локальная очистка.
- Нет единственного связанного Orders: конфликт API, а не выбор произвольной записи.
- Auth, 5xx или неожиданный ответ: processing_error с DEFERRED_TICKET_RECHECK_SECONDS.
Временная граница
Контекст рассчитывает:
planned_start— корректноеOrders.time_start;pre_start_at— planned_start минусSERVICE_REQUEST_PRE_START_DURATION_SECONDS;pending_at— pre_start_at минусSERVICE_REQUEST_BOOKED_PENDING_LEAD_SECONDS.
Это не отсчёт от даты создания Ticket. При отсутствующем/некорректном pending_at плановая граница не считается достигнутой; исправление даты может потребоваться отдельно. ASAP использует свою явную ветвь и не ждёт наличия pending_at.
Дату сравнивает runtime. Backend move_booked_order_to_pending_as_handler повторно проверяет актуальный BOOKED и отсутствие provider под блокировкой, но не пересчитывает время окна. Поэтому выбранный Python и именованные параметры тайминга являются частью политики перехода.
Канонические действия и внешние участники (BPMN)
Доставка через доверенный handler-intents и прямой actions API описаны в TEMPLATE. Ответ 202 relay не доказывает исполнение. Runtime принимает доверенное намерение в память, а backend повторно проверяет actor и актуальное состояние. После рестарта intent-очередь не заменяет persisted результат заказа.
Взять заказ
take доступен допустимому исполнителю, пока заказ BOOKED и provider ещё не назначен. Каноническая операция проверяет роль исполнителя сервиса, совместимый active Provider по service/company/resource, применимую политику одновременных заказов и требования выбранного исполнителя. Только затем сохраняет provider и переводит в ASSIGNED.
Подготовка недостающих check-действий может закончиться отказом взять заказ, если requirements ещё не удовлетворены. Появление такой заявки проверки не является успешным назначением, а этот BOOKED handler не обещает автоматически повторить уже отклонённый пользовательский take после её завершения. Нужно смотреть фактический ответ и состояние.
Отменить заказ
Допустимый автор/личный клиент может отменить свой BOOKED-заказ. Цель этой стадии — CANCELLED. Это отличается от отмены TEMPLATE, которая ведёт в CLOSED. Приоритет обработки queued intent перед автоматическим окном не отменяет backend-проверку актуального состояния и прав пользователя.
Перейти в PENDING
Узкий handler endpoint требует order.move_booked_to_pending, Ticket scope и единственный связанный заказ. Под блокировкой backend отвергает переход, если стадия уже не BOOKED или provider уже появился. Он не удаляет назначенного исполнителя ради поиска и не переводит заказ в PENDING по старому локальному снимку.
Успешный переход сохраняется каноническим action layer с Event и commit-событиями. Следующий владелец получает PENDING, прежний BOOKED исключает свой снимок по ticket.moved; потеря доставки восстанавливается scoped periodic reconciliation. Гонка take и автоматического перехода решается актуальным состоянием backend, а не очередностью уведомлений на экране.
Ожидание и диагностика
| Назначение | Настройка / состояние |
|---|---|
| Обычный повтор BOOKED | SERVICE_REQUEST_BOOKED_RECHECK_SECONDS, awaiting_pending_window |
| Плановое окно | SERVICE_REQUEST_PRE_START_DURATION_SECONDS и SERVICE_REQUEST_BOOKED_PENDING_LEAD_SECONDS |
| Общее исключение | DEFERRED_TICKET_RECHECK_SECONDS, processing_error |
| Сверка очереди | INTERVAL_TIME_BD_REQ |
Defer хранится в памяти и освобождает worker. Новая authoritative revision либо разрешённый queued intent могут сделать Ticket готовым раньше; повтор того же снимка не сбрасывает обычное ожидание. Фактический запуск зависит от соединения и свободного worker. Ошибка API-списка не равна подтверждённой пустой очереди.
При долгом BOOKED проверить:
- ASAP, planned_start и pending_at;
- действующие именованные параметры времени;
- актуальный provider;
- для take — результат relay, канонического действия, подготовленных проверок и сохранённый ASSIGNED.
BOOKED с заполненным provider требует разбора согласованности; удалять provider ради успешного PENDING нельзя. Ожидание планового окна штатно. Предложения кандидатам относятся к PENDING, поэтому их отсутствие в BOOKED само по себе не означает поломку.
Проверенные источники
Git SHA/SHA-256 и параметры моделей закреплены в metadata и documentation BPMN. Handler и бизнес-действия при анализе не выполнялись; изменение источников требует повторного сопоставления.
- sharix-open-handlers-examples / handlers/open_service_request_booked.py — Git 76e0c693b628ed4a1fa34515a3f8abdff26149bb.
- sharix-open-handlers-examples / generated_handler_blocks/open_service_request_booked.json — Git 76e0c693b628ed4a1fa34515a3f8abdff26149bb.
- sharix-open-handlers-examples / catalog.py — Git 76e0c693b628ed4a1fa34515a3f8abdff26149bb.
- sharix-open-handlers-backend / core/blockly_runtime.py — Git 50baf376e224d915a87d63240f3f339b3dda9afa.
- sharix-open-handlers-backend / core/requesters.py — Git 50baf376e224d915a87d63240f3f339b3dda9afa.
- sharix-open-handlers-backend / core/order_action_messages.py — Git 50baf376e224d915a87d63240f3f339b3dda9afa.
- sharix-open-handlers-backend / ticket_blockly_codegen.py — Git 50baf376e224d915a87d63240f3f339b3dda9afa.
- sharix-open-handlers-backend / ticket_codegen_contract.json — Git 50baf376e224d915a87d63240f3f339b3dda9afa.
- sharix-open-tickets / lib/tickets.py — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
- sharix-open-tickets / api/handler_auth.py — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
- sharix-open-tickets / signals.py — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
- sharix-open-tickets / services/handler_wakeup.py — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
- sharix-open-backend / apiviews/handler_order_workflow.py — Git 778a3280cee115ba0efe3fdff7b0e708b0c10093.
- sharix-open-backend / apiviews/open_api.py — Git 778a3280cee115ba0efe3fdff7b0e708b0c10093.
- sharix-open-backend / lib/order_handler_relay.py — Git 778a3280cee115ba0efe3fdff7b0e708b0c10093.
- sharix-open-backend / lib/handler_order_context.py — Git 778a3280cee115ba0efe3fdff7b0e708b0c10093.
- sharix-open-backend / lib/order_workflow_policy.py — Git 778a3280cee115ba0efe3fdff7b0e708b0c10093.
- sharix-open-backend / lib/order_actions.py — Git 778a3280cee115ba0efe3fdff7b0e708b0c10093.
- sharix-open-backend / lib/order_permissions.py — Git 778a3280cee115ba0efe3fdff7b0e708b0c10093.
- sharix-open-backend / urls.py — Git 778a3280cee115ba0efe3fdff7b0e708b0c10093.
- sharix-open-backend / lib/order_lifecycle.py — Git 778a3280cee115ba0efe3fdff7b0e708b0c10093.
- sharix-open-backend / lib/order_provider_requirements.py — Git 778a3280cee115ba0efe3fdff7b0e708b0c10093.