Содержание
ST_REQUEST в WONTFIX: отрицательный результат и решение о закрытии
Назначение: Сценарий процесса. Продукт: ShariX Open.
Для кого: Разработчик · Поддержка · Рецензент и приёмщик · Нейросеть.
Темы: Обработчики → ST_REQUEST · Доступ → Требования · Обработчики → Blockly.
Область: ShariX Open. Обработчик: open_st_request_wontfix, тип ST_REQUEST (1), рабочий статус WONTFIX (149). 31.10.2026 исходники повторно получены из Git. Обе Python-копии совпали с новой канонической генерацией Blockly. Сам обработчик и его внешние действия при анализе не запускались. Выбранная версия, настройки и работоспособность конкретной установки проверяются отдельно.
Назначение и границы
Для обычной заявки WONTFIX:
- фиксирует уже принятое решение «не будет исправлено»;
- ожидает отдельного решения о закрытии;
- не выбирает основание отказа и не добавляет объяснение в карточку;
- не закрывает заявку по таймеру.
STREQ_AUTOACCEPT здесь не используется.
Для document-verification-v1 и requirement-check-v1 действует профильное завершение:
- Backend фиксирует отрицательный результат конкретной проверки.
- Пересчитывает связанных потребителей.
- Runtime отправляет итоговое уведомление.
- Отдельно запрашивает CLOSED.
Это не глобальное удаление документов, отзыв всех прежних подтверждений или деактивация связанных объектов.
Оба BPMN-процесса имеют isExecutable=false. Это описание реализации, а не исполняемый workflow Wiki. Runtime выполняет выбранный проверенный Python из Blockly. End event завершает показанную операцию, а не утверждает успех всего продукта.
Один проход, ожидание и закрытие (BPMN)
- Снимок уже не в
WONTFIX— запросить удаление Ticket из локальной очереди и удаление комнаты. - Обычный Ticket — записать локальную причину
support_closure_decision, назначить defer поST_REQUEST_WONTFIX_RECHECK_SECONDSи освободить worker. Причина в журнале defer —st_request_wontfix; сохранённая локальная причина остаётсяsupport_closure_decision. - Профильный контракт — вызвать
complete_verification_workflow. Scoped backend API требует handler identity, capabilityverification.workflowи доступ к данному Ticket. Успешный ответ обрабатывается отдельно от смены статуса: уведомления, журнал, затем запросCLOSEDчерез scoped Ticket API.
404 при переходе в CLOSED запрашивает локальную очистку как для устаревшего контекста. Ошибки отправки/перехода вне локального catch приводят к общему processing_error и DEFERRED_TICKET_RECHECK_SECONDS; уже committed доменный результат не откатывается.
Отрицательное завершение в backend (BPMN)
Complete на dbsynce/api/handler/ticket/{ticket_id}/verification/:
- Прочитать marker verification_runtime.completed.
- Если результата ещё нет — потребовать DONE либо WONTFIX. Для WONTFIX выбрать отрицательный результат.
- Определить actor: явный аргумент, затем reviewer_user_id ручного результата, затем assigned_to.
- Применить соответствующий контракт документа либо RequirementCheck.
Handler API явный actor не передаёт. Повтор с marker имеет отдельное поведение, описанное ниже.
Отказ в проверке документа
Для document-verification-v1 отрицательная ветвь сохраняет outcome=failed и комментарий результата. Она не создаёт DocumentVersion, не удаляет существующую проверенную версию и не меняет её на «отрицательную версию». Проверки актуальности draft_revision, которые выполняются при положительном создании версии, в этой отрицательной ветви не запускаются.
Отказ по новой заявке не следует трактовать как автоматическое аннулирование старого проверенного документа. Если нужен отзыв прежнего подтверждения или замена документа, это отдельное доменное действие; текущий обработчик не выполняет его скрыто.
Отказ по RequirementCheck
Для requirement-check-v1:
- связанная попытка должна существовать;
- у PENDING применяется passed=False, actor, комментарий и применимые поля баллов через доменную операцию;
- проверяются связь с Ticket, допустимость завершения попытки и обязательный ответственный.
Высокий балл не превращает явный отрицательный результат в положительный.
Если попытка уже завершена:
- FAILED: совместимо с WONTFIX.
- PASSED или иное несовместимое состояние: ошибка, прежний результат не перезаписывается.
- Попытка отсутствует: ошибка связи.
Нужно сверить Ticket и фактическую попытку, а не считать complete успешным по самому запуску handler.
Пересчёт потребителей
После отрицательного результата backend всё равно вызывает reevaluate_ticket_consumers: собирает найденных потребителей, вычисляет требования, при ok=true вызывает resume_approved_activation. Это не отмена отказа. Другие действительные подтверждения и требования могут сохраняться, поэтому итог ok не выводится только из одного WONTFIX.
Возобновление следует канонической границе ранее одобренной активации. Для ACCESS_REQUEST/NEG_REQUEST будится текущий handler; для исторического ST_REQUEST проверяется соответствующий gate. Отрицательная проверка не выдаёт новое одобрение, не обходит требования и не означает автоматическую деактивацию.
Backend сохраняет marker, outcome и consumer_evaluations, возвращает итоговое сообщение автору. Runtime после успешного ответа запрашивает CLOSED; он не требует положительного outcome или успеха всех consumer evaluations перед закрытием Ticket. Закрытие отрицательной проверки является штатным поведением.
Повтор и частично выполненная последовательность
Повторный complete при сохранённом marker возвращает прежние outcome/details и ещё не подтверждённое уведомление. Результат и consumer evaluations заново не вычисляются. Поэтому marker — граница идемпотентности этого Ticket, а не команда пересмотреть ранее сохранённое решение после переоткрытия.
Частично выполненную последовательность разбирать по отдельным фактам:
- результат сохранён в backend, но ответ мог потеряться;
- уведомление отправлено, но ack мог не сохраниться;
- CLOSED мог ещё не сохраниться после успешного доменного результата.
Сначала перечитать эти состояния. Стирание marker или повтор отрицательного решения вслепую не исправляют транспортную ошибку.
Внешнее решение для обычной заявки
Обычный Ticket в WONTFIX остаётся на ожидании. Пользователь с доступом и правом смены статуса может выбрать CLOSED либо REOPENED согласно текущему lifecycle. Авторство само по себе не разрешает переход. Ветка autoaccept и автоматический таймер закрытия отсутствуют; очередной срок defer лишь разрешает новый проход.
После commit канонический backend направляет события смены владельца; прежний handler исключает локальный снимок по ticket.moved. При переоткрытии новый владелец — open_st_request_reopened. Отдельного open_st_request_closed в текущем каталоге нет. При потере события scoped periodic reconciliation восстанавливает состав очереди. Внешний пользовательский переход, commit и best-effort доставка XMPP разобраны также в сценарии IN_PROCESS.
Уведомления и интервалы
Итоговое уведомление получает автор через защищённый API получателей. Подтверждение ключа ack_notification сохраняется после попытки отправки; оно не доказывает прочтение человеком. Потеря ack может вызвать повтор сообщения, но не должна создавать второй доменный результат при сохранённом marker.
| Ситуация | Ожидание / причина |
|---|---|
| Обычная заявка | ST_REQUEST_WONTFIX_RECHECK_SECONDS; support_closure_decision, журнал st_request_wontfix |
Ошибка HTTP/разбора complete | 300 секунд; verification_completion_error |
| Иное исключение отправки/перехода | DEFERRED_TICKET_RECHECK_SECONDS; processing_error |
| Периодическая сверка | INTERVAL_TIME_BD_REQ; scoped список |
300 секунд — текущая константа Python. Defer находится в памяти и не занимает worker. Новая authoritative revision может снять ожидание; дубликат того же снимка — нет. После рестарта runtime заново сверяется с backend. Фактический запуск зависит также от соединения и свободного worker.
Что различать при диагностике
При диагностике сверить:
- Контракт и выбранную версию handler.
- Статус Ticket и состояние связанной попытки/документа.
- Marker completed, outcome и consumer_evaluations.
- Ключ ack уведомления.
- Отдельный результат перехода CLOSED.
Для обычной заявки ожидание решения штатно. Для профильной несовместимый терминальный результат требует разбора решения, а не только сетевой проверки.
Проверенные источники
Git SHA и SHA-256 закреплены в metadata и documentation BPMN. Изменение источников требует повторного сопоставления алгоритма и внешних контрактов.
- sharix-open-handlers-examples / handlers/open_st_request_wontfix.py — Git 76e0c693b628ed4a1fa34515a3f8abdff26149bb.
- sharix-open-handlers-examples / generated_handler_blocks/open_st_request_wontfix.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 / 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 / services/verification_results.py — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
- sharix-open-tickets / services/st_request_contracts.py — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
- sharix-open-tickets / utils.py — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
- sharix-open-tickets / views/ticket_detail.py — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
- sharix-open-tickets / api/views/handler_workflow.py — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
- sharix-open-tickets / signals.py — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
- sharix-open-tickets / services/handler_wakeup.py — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
- sharix-open-backend / apiviews/handler_workflow.py — Git 778a3280cee115ba0efe3fdff7b0e708b0c10093.
- sharix-open-backend / lib/verification_workflow.py — Git 778a3280cee115ba0efe3fdff7b0e708b0c10093.
- sharix-open-backend / lib/document_verification.py — Git 778a3280cee115ba0efe3fdff7b0e708b0c10093.
- sharix-open-backend / lib/verification_responsibility.py — Git 778a3280cee115ba0efe3fdff7b0e708b0c10093.
- sharix-open-backend / lib/verification_algorithms.py — Git 778a3280cee115ba0efe3fdff7b0e708b0c10093.
- sharix-open-backend / lib/requirement_checks.py — Git 778a3280cee115ba0efe3fdff7b0e708b0c10093.
- sharix-open-backend / lib/activation.py — Git 778a3280cee115ba0efe3fdff7b0e708b0c10093.