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

P>>>Тебе уже много раз рассказали.
P>·>Рассказано текущее положение дел у вас, а не обоснование чем такое решение лучше, чем альтернативы.
P>Ты альтернативу так и не показал, кроме "у нас есть рассылки" Рассылки сами все проблемы порешают?
Они решают проблемы как минимум не хуже, чем хедеры. А по некоторым параметрам — значительно лучше.

P>·>Под precondition я имею в виду идентификатор из твоего кода: Warning.assert(precondontion, 'unexpected input'). Тебя опять куда-то унесло в оффтопик.
P>Ну вот. А где здесь та самая комбинация и как её узнать на момент тестирования?
Как минимум — ровно тем же способом, которым ты её узнал во время добавления кода для твоего хедера.

P>>>Например — контрольная сумма. Гыгы. Не сходится — с реквестом вероятно чтото не то. Логируем, выставляем варнинг и возвращаем респонс.
P>·>Такую херню надо просто реджектить без вопросов.
P>Теоретически. А вот практически этот вариант не всегда реализуем, т.к. всегда будут какие нибудь варнинги.
Почему-то у большинства нет такой практики... ибо плохая практика. Я вот не сталкивался с публичными API от каких-нибудь известных контор типа FAANG. А ты?

P>А теперь твой ход — покажи, как ты подобную багу будешь искать тестами.
Причём тут тестирование? Мы вроде о warning headers говорим?

Впрочем отвечу, intermittent failures мы искали постоянным прогоном тестов в тестовых окружениях. С random, конечно, проблем не припомню, но всякие race conditions, эффекты асинхронности, зависимость от текущего времени, переход летнее-зимнее время — ловили. Никаких warning хедеров ясен пень. assert не проходит — это фатальное исключение и падение теста.

Более того, хедер может работать в принципе только в одном частном случае, когда на один запрос ожидается ровно один ответ, что, впрочем, типично для REST. Как только появляется какой-нибудь stream, websocket или типа того, то это вообще никуда не годится. А иметь два разных механизма — это полный бардак.

P>·>Перечитай вопрос внимательно. Почему именно хедер? Например, пусть ваш мониторинг аггрится на ERROR в логах и шлёт емейлы кому положено, напрямую. Зачем эти промежуточные слои через rest, чужой мониторинг, чужой L2 и т.п.?
P>Еще раз — емейл это крайне перегруженый канал. Слишком велик шанс что письмо тупо пропустят или прочитают слишком поздно.
Это не какой-то закон природы, а особенности вашей организации. Можно специальные адреса выделять для таких коммуникаций. Поручать определённым командам следить за анонсами. Ведь там не только изменения в API, а прочие другие события. Временные запланированные отключения, обновления сертификатов, адресов endpoints, каких-то настроек и т.п. Много важной информации может быть которую нельзя пропускать для обеспечения надёжного функционирования систем.

P>>>Например, потому что это самый простой и дешевый способ разграничить ответственность. Вкомитал вызов согласно этому АПИ — теперь отвечай сам за корректность запросов.
P>·>Некорректные запросы надо просто реджектить. Давай другой пример.
P>Пример тебе не нравится — это уже твои проблемы.
То что в хедер можно пихать всякую дичь никак не обосновывает необходимость хедера. Скорее наоборот.

P>>>Ага, в ответ на "escalate" прибегает архитектор, и говорит "делай хидер с варнингом, мне так приказали сверху, теперь всё апи будет таким."
P>·>Т.е. у вас так принято, культ карго. Так бы сразу и сказал.
P>Рашение административных проблем как правило занимает много времени, бывает даже годы, пока выработается и стабилизируется конкретный процесс.
P>А решение нужно прямо сейчас.
Ух ты. А вы хедер послали — и все административные проблемы решились прямо сейчас. Прям чудо. Пошли, плиз, этот хедер в президентам разных стран, мир во всём мире настанет.

P>>>Ты так и не рассказал, как будет без хидера
P>·>Сказал. После 0го шага идёт сразу 8й.
P>Это детские отписки. Поскольку ты закладываешься на емейл, слишком велик шанс что прочитают с запозданием. И на этот случай у тебя решения как не было, так и нет.
Если проблема очень ограничена во времени, могу и в чат, и позвонить, и даже ногами дойти.
А хедер у вас лично CEO читает в реальном времени, и тут же указания раздаёт. Так что-ли?

P>>>Что бы они приняли действия на своей стороне по исправлению проблемы.
P>·>Как это их обязует принимать действия? Почему они не могут предпринять те же действия, например, при получении емейла от вас?
P>Ты, похоже, не читаешь. Емейл слишком ненадежный канал. При условии, что люди относятся к обязанностям добросовестно, емейл не дает никаких гарантий — срочная работа на выезде, воркшоп, командировка, отпуск, итд итд. Упс — прочитали, но неделю спустя. Еще момент — человек просто устал и пропустил тот самый емейл.
P>А вот на звоночек в мониторинге реагируют очень быстро, и L2 суппорт в состоянии купировать большинство проблем.
L2 у нас и на емейлы реагирует. Работа у них такая. Бизнес и клиенты о своих проблемах емейлы шлют, в хедеры они не умеют.

P>>>В том то и дело, что мне и не надо это делать. Как только они вкомитали использование этого апи, теперь это их забота. Я могу гайдлайны подкинуть, типа "добавьте правило в мониторинг". Но контролировать свою сторону будут они сами.
P>·>Так чтение емейлов тоже их забота. В чём разница?
P>Ты усиленно игнорируешь всё, что я пишу про емейлы. Какой в этом смысл?
Ты проецируешь ваш бардак с коммуникационными каналами на всех. Я просто пытаюсь донести мысль, что ваша проблема с емейлами — это ваша проблема. Легко решаемая.

P>·>Да тоже самое. Оптимум — после 0го шага сразу 8й. Ну или 7й, может быть. Шаги 1-6 не нужны вообще.
P>Ну вот был воркшоп, чтение емейлов перенесли на завтра. Упс. Что делать?
С таким же успехом перенесут и анализ хедеров. Что делать?

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

P>>>Зато при траблшутниге, если их L2 суппорт придет ко мне, мне достаточно кидануть им одну ссылку, что бы они были в курсе, как починить.
P>·>Придёт так же в октябре. В чём разница-то?
P>При траблшутинге они заинтересованы решать всё быстро тк они несут убыток, и все вопросы решаются буквально голосом. Соответственно, мне не надо напоминать "а видели ли вы емейлы от нас полгода назад?"
Ужас. Если доходит до траблшутинга, то дело уже плохо.

P>Вместо этого "давайте глянем ваши логи... Видите — варнинг такой, следовательно, вам надо обновить вашу конфигурацию"
Т.е. ваши хедеры проблему не решили, а допустили до прода. А проблему, в итоге, решает не хедер, а голос. Полный фейл.

P>И дальше они справляются без меня. Моя цель в том и состоит, что бы предоставлять инструмент решения проблем, а не влазить в каждое из решений.
С таким же успехом можно показать что угодно, и логи, и старые емейлы, и вики, и changelogs и т.п., у кого бы они ни были.
И вообще, сложно себе представить, чтобы я должен был разбираться как мне кому-то показывать "ваши логи", и это у тысяч косьюмеров.

P>Искать, где чьи логи, это одна из проблем. Проще отфутболить тому, на чьей стороне косяк, пость он видит проблему в своих логах и своем мониторинге.
Мне проще быстро скопипастить свои логи, т.к. я знаю где что и как искать. Разбираться в чужих логах? Как? Да и доступа у меня может не быть, и никакого контроля.

P>Тогда ихние L2 смогут разобраться самостоятельно, и будут эскалировать не абы куда, а именно тем людям кто в данный момент может лучше разрулить.
Т.е. они по хедерам смогут разобраться?! Скорее всего потребуют changelog или типа того, для описания сути изменений.

P>·>Для этого не нужен хедер отправлять консьюмерам. Т.к. это всё навешивается у провайдера, а не у консьюмеров. Опять на ходу тему меняешь.
P>Тебе не нужно — ну не отправляй. Разве я тебя заставляю?
Никому не нужно. Если вам так хочется, то кто ж запретит. Ещё можете в бубен ударять, с таким же результатом. Всё равно будете голосом проблемы в проде решать.