Это старая версия документа!
Содержание
SERVICE_REQUEST в BOOKED: ожидание исполнителя и окно PENDING
Область: ShariX Open. Обработчик: open_service_request_booked, тип SERVICE_REQUEST (2), рабочий статус BOOKED (211). Опубликованный Python на 28.10.2026 побайтово совпадает с каноническим renderer Blockly workspace. Выбор версии на конкретном сервере проверяется отдельно.
Назначение и границы
Handler сопровождает размещённый заказ до назначения исполнителя либо перехода в PENDING. Сначала он пытается применить одно разрешённое пользовательское намерение take/cancel, затем проверяет текущее окно автоматического перехода. Он не выбирает кандидатов, не рассылает предложения и не проводит раунд победителя в BOOKED: это отдельная стадия 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.
404 контекста/action означает устаревший scope и запрашивает локальную очистку. Отсутствующий либо неоднозначный связанный Orders — конфликт API, а не выбор одной записи. Ошибки авторизации, 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. BOOKED с уже заполненным provider может получать доменный отказ перехода в PENDING и требует разбора согласованности, а не удаления provider ради успешной проверки. Для пользовательского take различайте relay, окончательный результат, подготовленные проверки и сохранённый ASSIGNED. Само ожидание планового окна штатно; отсутствие предложений кандидатам в этой стадии не доказывает поломку раунда PENDING.
Проверенные источники
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.