Correlation / trace ID¶

Часть невозвратного фундамента (event-bus-concept.md, раздел 10) и основа отладки асинхронной системы (раздел 8): в распределённом потоке это единственный способ собрать «что за чем произошло».

Стандарт¶

Используем W3C Trace Context — заголовок traceparent (00-<trace-id>-<span-id>-<flags>). Не изобретаем свой формат: он совместим с OpenTelemetry, который добавится позже (раздел 8) без переделки.

Где живёт ID¶

На шине (NATS): в заголовках сообщения (traceparent, при нужде tracestate). Не в payload — заголовки переживают маршрутизацию и не трогают схему события.
При входе в систему ID кладётся первым же продюсером. Если факт пришёл извне без traceparent — генерируется на границе (в мосте или у edge-участника) и дальше только пробрасывается, не переписывается.

Переход через границу с движком¶

Это слабое место — ID обязан пережить переход NATS → Inngest и обратно (раздел 5, 8):

Вход. Мост читает traceparent из заголовка NATS-сообщения и кладёт его в data события Inngest (напр. data.traceparent), т.к. Event API движка работает с телом события, а не с произвольными заголовками.
Внутри движка. Значение носится по шагам в данных функции.
Выход. Публикуя результат обратно в шину, функция/мост кладёт тот же traceparent обратно в заголовок NATS-сообщения.

Так одна цепочка остаётся сшитой сквозь оба слоя.

Правило¶

Любой новый участник, публикуя факт, обязан пробросить входящий traceparent, если он реагирует на другое событие. Обрыв correlation ID — дефект, ловится в ревью контракта (раздел 9).