НАЧАЛО >> Оглавление >> Общее описание >> История изменений >> Что нового в проекте I128 >> Версия 2026.3 >> [I128-2792] Зафиксировать runtime-контракт EventBus, Queue и TraceContext📄 Скачать в DOCX
| Тип | Версия | Статус | Приоритет | Исполнитель |
|---|---|---|---|---|
| ⚙️ Новые возможности | 2026.3 | 🔘 Завершено |
Средний | Ilya Mikhaylenko |
Компоненты: Нет
Завершено: 09.09.2026 23:37
Цель
Зафиксировать общий runtimeконтракт между системной событийной шиной EventBus, очередью фоновых заданий Queue и сквозной трассировкой TraceContext, чтобы workflow/taskсценарии выполнялись надежно, диагностируемо и без дублирования ответственности между модулями.
Контекст В промышленном контуре одно пользовательское действие может изменить запись, выполнить workflow-переход, записать историю 907, опубликовать событие, поставить фоновое задание, отправить уведомление и оставить диагностический след. Эти части должны быть связаны единым контрактом, но каждая должна оставаться у своего системного владельца.
Что Нужно Сделать
Описать общую модель выполнения операции: пользовательское действие, проверка прав, изменение записи, история 907, публикация события, постановка jobs, доставка внешним каналам, диагностика и восстановление.
Зафиксировать границу EventBus: хранит события, schemas, outbox/inbox, subscriptions, delivery attempts, idempotency registry и dead-letter для событий.
Зафиксировать границу Queue: хранит задания, очереди, worker state, retry/backoff/timeout, scheduling, progress, joblevel idempotency и deadletter для заданий.
Зафиксировать границу TraceContext: создает и распространяет trace id через UI, API, workflow, EventBus, Queue, transport, логи, HealthCheck и TestA evidence.
Зафиксировать классы выполнения: criticalstate, requiredintegration, optional-delivery, analytics. Для каждого класса определить, что может блокировать пользовательское действие, что уходит в outbox, что выполняется через Queue и что допускает best effort.
Зафиксировать единый формат ссылок между operation, event, job, delivery attempt, log entry и diagnostic report без хранения предметной логики в runtime-модулях.
Определить failure model: ошибка сохранения, ошибка публикации outbox, ошибка постановки job, ошибка delivery, повтор, dead-letter, ручной retry и безопасное сообщение пользователю.
Определить минимальный набор интерфейсов/DTO и providerконтрактов, которые должны использовать Workflow*, Tasks и другие модуливладельцы.
Подготовить сквозной e2e-сценарий первого промышленного контура: действие над записью проходит через workflow, event, queue job, file operation, security decision, log и diagnostic report.
Эта задача не должна превращаться в реализацию всей событийной шины, очереди или трассировки. Она должна зафиксировать общий контракт и проверяемую совместимость.
EventBus не должен выполнять job runtime; Queue не должна становиться event log; TraceContext не должен хранить доменную историю или audit.
Предметные модули определяют свои события, handlers, payload profiles и degraded policy; системные runtime-модули исполняют общий контракт.
Для разработчика любого модуля понятно, когда публиковать событие, когда ставить job, как передавать trace id и как оформлять idempotency key.
Одинаковое действие не дублируется при повторе UI/API/webhook/Queue.
Ошибка тяжелой доставки не откатывает уже сохраненную запись, если доставка относится к optional-delivery или analytics.
Критичные изменения состояния не считаются завершенными, если не зафиксирован обязательный event/outbox или другой required runtime artifact.
По trace id можно собрать безопасную диагностическую картину операции без чтения предметных таблиц вручную.
[I128-2793] Ввести TraceContext для сквозной трассировки операций
Статус: Завершено | Автор: Ilya Mikhaylenko
[I128-2794] Реализовать системную событийную шину EventBus
Статус: Завершено | Автор: Ilya Mikhaylenko
[I128-2795] Расширить Queue как runtime фоновых заданий, retry и расписаний
Статус: Завершено | Автор: Ilya Mikhaylenko