Здравствуйте, ·, Вы писали:

P>>·>Ровно то, что у тебя происходит на шаге 6 и 7.
P>>6 и 7 это работа L2 конкретной команды. А у тебя эту команду еще разыскать надо методом форварда емейлов и анализом трейсов.
·>У тебя ровно то же: А вот через транспорт однозначно известно, что происходит — нажали кнопку "показать трейсы" и сразу нашли, что вон тот сервис принадлежит команде ххх.
·>Или ты в прыжке переобуваешься?

В моем случае это делает L2 той самой команды, что обслуживает конкретный сервис. А в твоём случае её еще найти надо, через те же самые трейсы, тк у тебя этот сервис изначально неизвестен. Что предложишь, форвардить мессагу всем L2 и попросить, что бы они разыскали каждый своё? Или нанять человека, кторый будет диспетчером работать?

P>>·>Проблема в том, что у тебя в твоей схеме обрыв в коммуникации. До того как вам прибегут с прода злые клиенты ты не знаешь что происходит начиная с 4го шага.
P>>Если они прибегают, то мы спрашиваем у них request id и мы можем показать весь процессинг на нашей стороне.
·>Вот именно. Т.е. хедер не особо то и нужен.

Ты что, ногой читаешь или затылком?
У нас хидер нужден для другого кейса — мы им сообщаем что у них проблема.

P>>При условии добросовестной реализации или использования нашего клиента можно ожидать
·>Это слишком невероятное условие. Практически наверняка невыполнимое для тысяч консьюмеров.

Это минимальное условие, которое можно себе позволить.

P>>Отсюда ясно, что информирован будет L2 непосредственно того самого сервиса.
·>Проблема не в том, кто информирован, а в том, что коммуникация односторонняя. А следовательно non-guarateed message delivery.

С email выходит еще хуже. Например, регулярно случается кейс "ой, шота рассылки перестали ходить"

P>>А в твоём случае этого L2 еще найти надо будет перекидыванием тикетов и форвардом емейлов.
·>Или трейсом по request-id. Техническая реализация не так важна.

Всё равно нужно искать ту самую команду, а уже потом внутри нее разбираться с произошедшим. То есть — два шага.

·>Верно. Но совершенно необязательно диагностику прокидывать по тому же каналу.
·>Более того, это не всегда технически возможно использовать тот же канал. Ты так и не предложил как это делать в отличных от REST request-response случаях Т.е. решение, как минимум, не универсальное, а значит всё равно понадобится другое решение.

Ровно то же, только рендерить будем не в хидер, а в энвелоп "диагностика: { варнинг: "<описание или ссылка или еще что>" }"