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

P>·>У тебя ровно то же: А вот через транспорт однозначно известно, что происходит — нажали кнопку "показать трейсы" и сразу нашли, что вон тот сервис принадлежит команде ххх.
P>·>Или ты в прыжке переобуваешься?
P>В моем случае это делает L2 той самой команды, что обслуживает конкретный сервис. А в твоём случае её еще найти надо, через те же самые трейсы, тк у тебя этот сервис изначально неизвестен. Что предложишь, форвардить мессагу всем L2 и попросить, что бы они разыскали каждый своё? Или нанять человека, кторый будет диспетчером работать?
Я предполагаю такой механизм уже должен существовать. Неужели у вас нет способа найти другую команду по request-id? Ведь коммуникация может понадобиться совершенно по какой-то другой причине. Без всяких варнингов. Ведь может быть они делают всё правильно, а у вас что-то не получается. Неужели хедер это единственный способ коммуникации?

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

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

P>>>Отсюда ясно, что информирован будет L2 непосредственно того самого сервиса.
P>·>Проблема не в том, кто информирован, а в том, что коммуникация односторонняя. А следовательно non-guarateed message delivery.
P>С email выходит еще хуже. Например, регулярно случается кейс "ой, шота рассылки перестали ходить"
chase&escalate. Ведь email это двухсторонний канал. А хедер — односторонний. В этом основная беда.

P>>>А в твоём случае этого L2 еще найти надо будет перекидыванием тикетов и форвардом емейлов.
P>·>Или трейсом по request-id. Техническая реализация не так важна.
P>Всё равно нужно искать ту самую команду, а уже потом внутри нее разбираться с произошедшим. То есть — два шага.
Ты ж вроде заявлял, что у вас есть трейсы. С 0го шага вбиваешь request-id и трейсишь до той самой команды. И сразу на 6-7 шаг — на адрес их L2 или AD шлёшь мыло-джиру-whatever.

P>·>Верно. Но совершенно необязательно диагностику прокидывать по тому же каналу.
P>·>Более того, это не всегда технически возможно использовать тот же канал. Ты так и не предложил как это делать в отличных от REST request-response случаях Т.е. решение, как минимум, не универсальное, а значит всё равно понадобится другое решение.
P>Ровно то же, только рендерить будем не в хидер, а в энвелоп "диагностика: { варнинг: "<описание или ссылка или еще что>" }"
Ты так и не рассказал в энвелоп чего. Далеко не всегда есть конкретный response для данного request.