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

·>В changelog в любом случае можно поместить несравненно больше информации, чем в хедер.
И в changelog оно тоже есть, коды предупреждений на него и ссылаются. Только вот насколько регулярно вы читаете этот changelog? И сколько именно этих changelog вы читаете? Может, у вашей команды 5 сервисов, которые обращаются к 10 другим сервисам. И за всеми изменениями нужно следить. С метриками чуть проще. На dashboard делается сводная статистика "по команде" по предупреждениям. Если что-то есть, можно посмотреть в конкретные сервисы. В результате я получаю ровно одно место, за которым нужно регулярно следить. Например, заходить туда раз в неделю.

P>>А так у нас сразу есть звоночек от мониторинга — на сервисах 0, 8, 124 варнинги, реквест-респонс прилагаются. дальше l2 разбирается, что откуда куда пришло, по трейсингу, и
·>Это всё средства.
А в чем проблема с данными средствами? Они же (в простейшем варианте) дешевые. Настолько сложно добавить заголовок в ответ? Или очень сложно посмотреть на заголовки ответа и увеличить метрику? Хотя да, почему-то второе сейчас является большой проблемой для программистов .

P>>дает знать команде соответсвующего сервиса, что у них чтото там не то.
·>А вот и цель. Так чем это принципиально отличается от емейла?
Сложнее пропустить или забыть со временем. Настроенные алерты по метрикам (например, раз в неделю) — отличная напоминалка. Нет вероятности, что про конкретного пользователя системы забудут. И нет лишнего спама, когда changelog рассылается всем "на всякий случай". Сразу видна релевантность. Не нужно думать о том, затрагивают ли изменения именно ваши сервисы или нет. Можно делать сводные метрики и статистику "по команде" а не 10 списков по отдельным сервисам.

Есть и неочевидное преимущество. Предупреждения автоматические и не зависят от человека. Они могут находить "заброшенные" ветки в коде. Например, есть у нас сценарий, который встречается 3-4 раза в неделю. Он реализован уже давно, работает уже больше года без изменений. И вот какое-то API, используемое в этом редком случае, меняется. Какова вероятность того, что разработчики сервиса вспомнят про этот редкий случай и обновят использование там? Обнаружат ли забытое изменение во время тестов (и если да, то как)? В случае заголовка обычно чуть проще. Заголовок обрабатывается на уровне обертки вокруг http-клиента (т.е. универсально). Забытый сценарий будет отображен на метриках. И у команды будет еще много времени на то, чтобы найти и обновить использование API.

P>>Например, мониторинг может подсказать, что после передеплоймента какого то из сервисов часть клиенты начали получать варнинги, и это стоит проверить.
·>Уже поздно. Хотя... если придерживаться принципа "лучше поздно, чем никогда"... то может и ок. Но это как последняя линия обороны.
Не поздно. Ничего непоправимого пока не произошло. Так что этот заголовок из серии "лучше иметь чем не иметь".

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Клиент это программа. Толку от того что она что то увидит никакого.
Какая программа? Если браузер — да, смысла никакого. Если же это другое (серверное) приложение, то как минимум она может увеличить метрику. Свою метрику. Потому что переходить на новое API нужно команде, отвечающей за приложение-клиента.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>А чтобы простимулировать переход — рассылаем им письма. Добавление твоего хидера проблему никак не лечит.
У меня в основном внутрикорпоративные клиенты. И один из самых лучших методов стимуляции — эскалация к общему начальнику. Отлично работает! "Я им и письма послал, и заголовки сделал, чтобы они могли сами все увидеть, а они ни в какую". С начальником еще и SLA по обратной совместимости можно обсудить. Так что когда что-то через три месяца сломается — моя совесть будет чиста.

Здравствуйте, Ночной Смотрящий, Вы писали:

M>>Клиент — внутренний и не особо нас любит. Причем не любит "просто-так"

НС>
НС>И зачем тогда об этих прекрасных отношениях внутри вашей организации писать сюда, преподнося это как аргумент?

Внутренние клиенты есть всегда. Вот внешние — это далеко не обязательно. Скажем, доля рестовых коммуникаций сильно скукожилась т.е. новые околобраузерные веяния вытесняют рест и задвигают его в приватную сеть.
То есть, браузер фактически общается с api gateway, а реальный rest сервис сидит в приватной сети. То есть, api gateway для нас это внутренний консумер. Сервис, который обращется к другому сервису — снова внутренний консумер. Бакенд обращается к кучке сервисов — снова внутренний консумер.
Даже если мы продаём API, то всё равно напрямую никто не лезет в приватную сеть минуя файрволы и гатевеи. Отсюда ясно, что чуть ли не все непосредственные консумеры это внутренние.
И вот на такой api gateway как правило навешиваются самые разные капабилити, и не важно, где они документированы, в open source, как трейсинг, или во внутренней документации экосистемы.

Более того, часто продукты используют пакет X-саpability не напрямую, а в составе какого то компонента как депенденси 2го уровня. Отсюда ясно, что changelog ничем не помогает — мало кто способен отслеживать все n*m зависимостей 2го уровня.
Например, им нужен не "умный клиент к сервису AБЦ", а "источник данных для аналитики". Аналитика пишется другой командой, и это просто пакет, который умеет тащить данные из разных источников и обрабатывать их. Соответственно, как только в конфиге появилась строчка "analytic-source": { "use-provider": "odata", "endpoint": "${analytic-endpoint}" } то у нас вдруг играет тот самый кейс — обновили чего то там, а эффекты появляются здесь. И при этом команда конкретного продукта абсолютно не в курсе, какие из её компонентов что то там унутре делают. Все что им надо — подлючили пакет аналитики, прикрутили роут, подкинули страничку-стили и всё готово.
Далее, при деплое зависимости 2го уровня могут малёха поменяться, так, по мелочи. Кто будет курить changelog n*m таких зависимостей?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>А не проще тогда в лог или метрику сразу писать, а не пересылать зачем то в хидерах клиентам?
В чей лог? В лог моего сервера писать бесполезно. Я прекрасно знаю, что API было объявлено deprecated (или что там у нас по сообщению). И раз изменение там, значит, я уже принял решение совсем убрать API через некоторое время. И должно очень многое измениться, чтобы я изменил свое решение. (Хотя внутренняя метрика тоже будет собираться, это да). Сейчас очередь что-то менять уже за клиентами. Нужно уведомлять их. Да, им будут письма и changelog. Но их можно забыть или пропустить на общем фоне. Или забыть про какой-то редкий сервис (например, работающий раз в неделю по таймеру). А еще нужно бы доставлять уведомления только релевантным клиентам. Может, из трех клиентских приложений изменения потребуются только в одном? Т.е. задача в том, чтобы как-то воздействовать на сервис-клиента.

Да, в некотором виде можно делать метрику "для другой команды". Делать "произвольные" метрики я не очень хочу. Например, максимум, что я могу различать — это внутренний логин или токен приложения. А что если у них несколько различных модулей ходят под одним логином? (Например, web-api и докатка транзакий, отвалившихся из-за сетевой ошибки). Я на сервере не смогу их отличить. А вот клиент вполне может иметь нужные идентификации метрик, чтобы сказать "да, докатчик-то мы и забыли". Поэтому в моей философии проще дать клиенту достаточно гибкие средства и пусть они используют их так, как могут. Метрики в Service Mesh здесь были бы идеальным вариантом. Но, опять же, я должен сказать мешу, что "вот в процессе этого обмена сообщениями есть подозрительные вещи". А не просто посчитать, сколько у меня было сомнительных клиентов.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>И зачем тогда об этих прекрасных отношениях внутри вашей организации писать сюда, преподнося это как аргумент?
Например затем, чтобы показать, что технические средства все-таки решают реальные проблемы. В том числе — и проблемы неэффективных организаций. Все-таки приходится разрабатывать системы в коллективах с реальными людьми. Можно ждать, пока огранизация станет идеальной (не станет). Можно решать по мере сил. Технические решения, которые работают только в строго контроллируемых условиях меня мало интересуют.

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

P>>>changelog содержит мизерное количество информации — название, ссылка на тикет, подробности, каменты, пул-реквест и тд. Отсюда далеко не всегда ясно, каким именно будет поведение конкретной системы. Соответсвенно, придется 1. прогнать тесты для всех n-систем/сервисов 2. надеяться, что в тестах будет прокрыта именно та самая ветка(и тут надо вспомнить, что не существует таких гарантий).
P>·>В changelog в любом случае можно поместить несравненно больше информации, чем в хедер.
P>changelog сам пойдет тестировать задеплоеные сервисы и
Ну да, естественно. Деплоймент и прогон тестов называется. Выкатываешь новую версию и смотришь какие тесты упали.

P>проверять, покрывают ли тесты все критические места или нет?
У тестов должно быть ровно два состояния — PASS и FAIL. Чем тут помогут warnings?

P>>>Т.е. все равно придется подкрутить мониторинг, что бы он хоть как то детектил проблемы, на случай п.2 А так у нас сразу есть звоночек от мониторинга — на сервисах 0, 8, 124 варнинги, реквест-респонс прилагаются. дальше l2 разбирается, что откуда куда пришло, по трейсингу, и
P>·>Это всё средства.
P>Это автоматизируется.
Добавление хедеров и варнингов в правильных местах? Правильная реакция на неправильные хедеры? Что именно автоматизируется-то?

P>А changelog — нет.
changelog автоматизировать на порядки легче. Даже во всяких github/jira это всё из коробки.

P>>>дает знать команде соответсвующего сервиса, что у них чтото там не то.
P>·>А вот и цель. Так чем это принципиально отличается от емейла?
P>Степенью автоматизации.
Верно. Емейлы-то элементарно автоматизируются. Чего не скажешь о кастомных хедерах.

P>>>Например, мониторинг может подсказать, что после передеплоймента какого то из сервисов часть клиенты начали получать варнинги, и это стоит проверить.
P>·>Уже поздно. Хотя... если придерживаться принципа "лучше поздно, чем никогда"... то может и ок. Но это как последняя линия обороны.
P>Неважно, первая или последняя. Закладываться на один только changelog идея так себе — например, некто забыл включить строчку этот changelog. Приплыли.
Тесты должны упасть.

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

M>·>Ну если клиент важный и платит много денег, то можно добиться реакции на письмо. Если на мыло не отвечают совсем, то можно даже позвонить и даже ногами прийти.
M>Клиент — внутренний и не особо нас любит. Причем не любит "просто-так", а не за то, что и как мы делаем. И вообще он по иерархии того же уровня, что и моя команда. Так что это совсем не моя обязанность в течение трех месяцев уговаривать их перейти на новый API.
А посылать хедер в течение трёх месяцев — обязанность что-ли? Хедеры обладают какой-то более сильной уговаривающей силой или что?

M>>>API выдавало предупреждения уже 3 месяца. Вон, в Istio нарисовано же в метриках.
M>·>А это бесмысленная попытка решать административные проблемы техническими средствами.
M>Почему бессмысленая? Как раз таки очень осмысленная. По результату всех принятых мер я и моя команда находимся в хорошем положении. Если что-то не работает — это не наши проблемы! Этим и достигается цель. Да, я могу выслушать грустную историю. Предложить административные пути. Например, увеличить сроки обратной совместимости (и, соответственно, быть готовым к уменьшению нашей скорости разработки). Или провести лекцию о метриках и мониторинге для той команды, которая три месяца предпочитала ничего не замечать. С техническими средствами я сделал все, что было в моих силах в рамках моей зоны ответственности. А без технических средств я останусь виноватым в недостаточной коммуникации. С учетом того, что я формально разработчик — выбор очевиден.
Непонятно в чём принципиальная разница незамечания емейлов от незамечания хедеров.
Незамеченный емейл можно вышестоящему начальству форварднуть, а что делать с незамеченным хедером — совсем неясно.

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

НС>>Клиент это программа. Толку от того что она что то увидит никакого.
M>Какая программа? Если браузер — да, смысла никакого. Если же это другое (серверное) приложение, то как минимум она может увеличить метрику. Свою метрику.

Для этого надо знать про твои хидеры и специально туда в клиента засунуть код, который метрику будет писать. Какой то интересный у тебя получается клиент. С одной стороны емейлы и релизноты читать не хочет, но метрику с твоим кастомным хидером во все свои проекты засунуть готов.
Собственно, в текущем проекте у меня была похожая проблема. Мы делали breaking changes, писали об этом в релизнотах и проговаривали на демах, а потом все равно прибегали плачущие товарищи с воплями, что у них все сломалось.
Решилась проблема чисто административными методами — заставили всех затронутых в обязательном порядке внимательно читать релизноты, благо они обычно не гигантские. И, как по волшебству, все проблемы исчезли.

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

НС>>А чтобы простимулировать переход — рассылаем им письма. Добавление твоего хидера проблему никак не лечит.
M>У меня в основном внутрикорпоративные клиенты. И один из самых лучших методов стимуляции — эскалация к общему начальнику. Отлично работает!

Или так.

M> "Я им и письма послал, и заголовки сделал

Заголовки тут — абсолютно лишняя сущность.

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

P>То есть, браузер ...
P>Даже если мы продаём API ...
P>И вот на такой api gateway ...

У меня текущий продукт ровно по такой схеме и построен. Только при чем тут заголовки с варнингами?

P>Более того, часто продукты используют пакет X-саpability не напрямую, а в составе какого то компонента как депенденси 2го уровня. Отсюда ясно, что changelog ничем не помогает — мало кто способен отслеживать все n*m зависимостей 2го уровня.

Зависимости 2-го уровня тебе и заголовки не помогут отследить, они ж только на одном уровне присутствуют. А релизноты непосредственных зависимостей ты читать обязан, и заголовки — крайне фиговая им замена.

P>Например, им нужен не "умный клиент к сервису AБЦ", а "источник данных для аналитики". Аналитика пишется другой командой, и это просто пакет, который умеет тащить данные из разных источников и обрабатывать их. Соответственно, как только в конфиге появилась строчка "analytic-source": { "use-provider": "odata", "endpoint": "${analytic-endpoint}" } то у нас вдруг играет тот самый кейс — обновили чего то там, а эффекты появляются здесь.

Заголовки тут не спасут.

P>Далее, при деплое зависимости 2го уровня могут малёха поменяться, так, по мелочи. Кто будет курить changelog n*m таких зависимостей?

Заголовки тут не спасут.

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

M>Можно ждать, пока огранизация станет идеальной (не станет).

Не надо ждать идеала. Надо решить конкретную проблему административным способом — это быстрее, дешевле и не создает оверхеда в работающей системе.

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

НС>>А не проще тогда в лог или метрику сразу писать, а не пересылать зачем то в хидерах клиентам?
M>В чей лог? В лог моего сервера писать бесполезно. Я прекрасно знаю, что API было объявлено deprecated (или что там у нас по сообщению).

Ну и прекрасно. Осталось сделать даш и предоставить к нему доступ клиентам, чтобы они могли в реальном времени наблюдать свои косяки. Можешь даже настроить репликацию нужной части своих метрик в их кластер, если он у них другой. Это все равно будет намного лучше какого то неизвестного хидера, засирающего боевой обмен.
Наконец, ты у себя можешь настроить алерты, которые будут рассылаться пациентам в автоматичном режиме.

M>А что если у них несколько различных модулей ходят под одним логином?

Это их проблема. Пусть UA корректно выставляют, к примеру.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Это тоже бессмысленно, потому что в нормальном REST url будет вида /api/vXX/collection. И в рамках конкретного vXX никаких ломающих изменений и устаревших API в принципе быть не может.
НС>·>Не может, конечно. Но есть, и будет есть всегда! Баги всё ещё не отменили.
НС>Все равно передавать это в каждом респонсе бессмысленно. Достаточно возвращать это в каком нибудь /status или /health.
Да, может быть достаточно. В общем случае — недостаточно, например, если есть какой-нибудь load balancer, который потенциально может распределять запросы инстансам разных версий.

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

·>например, если есть какой-нибудь load balancer, который потенциально может распределять запросы инстансам разных версий.

Это уже какой то абсурд.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·>например, если есть какой-нибудь load balancer, который потенциально может распределять запросы инстансам разных версий.
НС>Это уже какой то абсурд.
Это спека REST. Там каждый запрос независим и может обрабатываться разными серверами.
Берёшь какой-нибудь kubernetes и там такое как минимум во время деплоев происходит.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>У меня текущий продукт ровно по такой схеме и построен. Только при чем тут заголовки с варнингами?

При том, что трафик после такого гатевея уже внутренний, а раз так, то на него можно навешивать какие угодно капабилити. Т.е. приложение переписывать не нужно, а только переконфигурить сам гатевей который обычно не часть приложения, т.е. его можно пичкать какой угодно логикой. Например, гатевей будет блокировать реквесты от конкретных юзеров, клиентов, если варнинги идут больше недели.

НС>Зависимости 2-го уровня тебе и заголовки не помогут отследить, они ж только на одном уровне присутствуют. А релизноты непосредственных зависимостей ты читать обязан, и заголовки — крайне фиговая им замена.

1. сhangelog это в чистом виде человеческий фактор. например, девелопер не просмотрел, не учел последствия. Или поставил в тикете не ту версию, или не тот статус, или вообще забыл про статус. Или случайно вмергал. Или xxx-yyy других причин. И в changelog ничего внятного просто нет.
А может быть changelog просто дикий, вбросили адову кучу мелких фиксов и обновлений зависимостей, а у вас эта либа используется повсюду.
2. И вот ты прочел changelog, проверил все что мог, тебя тесты зелёные. Твои действия? Что конкретно ты будешь предпринимать
в такой вот ситуации? Есть хороший пример, что бы не абстрактно рассуждать? ты то не надеешься на варнинги, как с проблемой будешь работать?

P>>Например, им нужен не "умный клиент к сервису AБЦ", а "источник данных для аналитики". Аналитика пишется другой командой, и это просто пакет, который умеет тащить данные из разных источников и обрабатывать их. Соответственно, как только в конфиге появилась строчка "analytic-source": { "use-provider": "odata", "endpoint": "${analytic-endpoint}" } то у нас вдруг играет тот самый кейс — обновили чего то там, а эффекты появляются здесь.

НС>Заголовки тут не спасут.

Зато это уже можно автоматизировать. А вот как автоматизировать обработку changelog депенденсов 2го уровня — не ясно.

P>>Далее, при деплое зависимости 2го уровня могут малёха поменяться, так, по мелочи. Кто будет курить changelog n*m таких зависимостей?

НС>Заголовки тут не спасут.

Это смотря как ты ими пользоваться будешь.

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

P>>changelog сам пойдет тестировать задеплоеные сервисы и
·>Ну да, естественно. Деплоймент и прогон тестов называется. Выкатываешь новую версию и смотришь какие тесты упали.

Очевидно — никакие. Дальше что?

P>>проверять, покрывают ли тесты все критические места или нет?
·>У тестов должно быть ровно два состояния — PASS и FAIL. Чем тут помогут warnings?

Подозреваю, щас у тебя будет очередной аргумент "а надо писать без багов". 100% покрытие просто недостижимо, даже если считать по строчкам кода. Отсюда ясно, что должны быть другие механизмы обнаруживать и репортить ошибки
1. логирование
2. мониторинг
3. эксплорейтори тестирование (не путать с рандомным)
4. ассерты, варнинги, фолты, итд

P>>>>Т.е. все равно придется подкрутить мониторинг, что бы он хоть как то детектил проблемы, на случай п.2 А так у нас сразу есть звоночек от мониторинга — на сервисах 0, 8, 124 варнинги, реквест-респонс прилагаются. дальше l2 разбирается, что откуда куда пришло, по трейсингу, и
P>>·>Это всё средства.
P>>Это автоматизируется.
·>Добавление хедеров и варнингов в правильных местах? Правильная реакция на неправильные хедеры? Что именно автоматизируется-то?

Тебе что, не ясно, что такое мониторинг? Цитирую себя:
"А так у нас сразу есть звоночек от мониторинга — на сервисах 0, 8, 124 варнинги, реквест-респонс прилагаются. дальше l2 разбирается, что откуда куда пришло, по трейсингу, и "


P>>А changelog — нет.
·>changelog автоматизировать на порядки легче. Даже во всяких github/jira это всё из коробки.

ну написано в там — пофиксили уязвимость в парсере. твои тесты зелёные. Дальше что?

P>>Степенью автоматизации.
·>Верно. Емейлы-то элементарно автоматизируются. Чего не скажешь о кастомных хедерах.

С емейлами одна проблема — это в чистом виде человеческий фактора, например, потому что "устал, много писем, (не)прочитаю в понедельник"
Я например регулярно сталкиваюсь с ситуацией , что какой либо менеджер не отвечает на письма. Думаешь если ему подкинуть еще сотню-другу емейлов, так он быстрее разгребется?

P>>Неважно, первая или последняя. Закладываться на один только changelog идея так себе — например, некто забыл включить строчку этот changelog. Приплыли.
·>Тесты должны упасть.

Ну ок — реквест состоит из 100 переменных true-false, как долго будешь искать, какая же комбинация "та самая"?

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

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

P>>>проверять, покрывают ли тесты все критические места или нет?
P>·>У тестов должно быть ровно два состояния — PASS и FAIL. Чем тут помогут warnings?
P> Подозреваю, щас у тебя будет очередной аргумент "а надо писать без багов". 100% покрытие просто недостижимо, даже если считать по строчкам кода. Отсюда ясно, что должны быть другие механизмы обнаруживать и репортить ошибки
P>1. логирование
P>2. мониторинг
P>3. эксплорейтори тестирование (не путать с рандомным)
P>4. ассерты, варнинги, фолты, итд
Это всё внутренняя кухня. Зачем это слать наружу, в каждом респонзе и засирать прод трафик-то? С учётом того, что консьюмеры это могут всё влёгкую игнорировать.

P>>>·>Это всё средства.
P>>>Это автоматизируется.
P>·>Добавление хедеров и варнингов в правильных местах? Правильная реакция на неправильные хедеры? Что именно автоматизируется-то?
P>Тебе что, не ясно, что такое мониторинг? Цитирую себя:
P>"А так у нас сразу есть звоночек от мониторинга — на сервисах 0, 8, 124 варнинги, реквест-респонс прилагаются. дальше l2 разбирается, что откуда куда пришло, по трейсингу, и "
Ты обещал автоматически. Как автоматически появится такой мониторинг? И как ты убедишься, что этот мониторинг есть и выдаёт адекватные сигналы? Кто будет проверять эти сигналы? Никакой автоматики я пока не вижу — всё придётся вручную сооружать, расставлять эти варнинги, майнтейнить, анализировать и... в итоге слать менеджерам письма, чтобы они на эти варнинги хоть как-то реагировали. Не проще ли сразу начать с писем?

P>>>А changelog — нет.
P>·>changelog автоматизировать на порядки легче. Даже во всяких github/jira это всё из коробки.
P> ну написано в там — пофиксили уязвимость в парсере. твои тесты зелёные. Дальше что?
Ты сценарий не с потолка бери, а начни с того, как тебе помогут варнинг-хедеры и каким образом они появятся _автоматически_ как ты обещаешь.

P>>>Степенью автоматизации.
P>·>Верно. Емейлы-то элементарно автоматизируются. Чего не скажешь о кастомных хедерах.
P>С емейлами одна проблема — это в чистом виде человеческий фактора, например, потому что "устал, много писем, (не)прочитаю в понедельник"
P>Я например регулярно сталкиваюсь с ситуацией , что какой либо менеджер не отвечает на письма. Думаешь если ему подкинуть еще сотню-другу емейлов, так он быстрее разгребется?
Ясно. Хедеры значит этот менеджер читает, а на емейлы сил уже не хватает.

P>>>Неважно, первая или последняя. Закладываться на один только changelog идея так себе — например, некто забыл включить строчку этот changelog. Приплыли.
P>·>Тесты должны упасть.
P>Ну ок — реквест состоит из 100 переменных true-false, как долго будешь искать, какая же комбинация "та самая"?
Не дольше, чем искать для какой комбинации нужен варнинг.

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

P>>Очевидно — никакие. Дальше что?
·>Дальше работаем.

Очевидно, ты проигнорировал проблему. А вот наличие варнингов можно словить мониторингом и зарепортать.
Ровно так же работают и логи, ассерты и многие вещи. Хидер нужен в том случае, что бы уведомить вызывающую сторону тем или иным способом. Например, если клиент предоставляешь свой собственный.

·>Это всё внутренняя кухня. Зачем это слать наружу, в каждом респонзе и засирать прод трафик-то? С учётом того, что консьюмеры это могут всё влёгкую игнорировать.

Внутренние консумеры не могут. А это бОльшая часть трафика. Внешние — тоже могут учитывать.

P>>"А так у нас сразу есть звоночек от мониторинга — на сервисах 0, 8, 124 варнинги, реквест-респонс прилагаются. дальше l2 разбирается, что откуда куда пришло, по трейсингу, и "
·>Ты обещал автоматически. Как автоматически появится такой мониторинг? И как ты убедишься, что этот мониторинг есть и выдаёт адекватные сигналы? Кто будет проверять эти сигналы?

Добавить правило в мониторинг это дело секунд. Все остальное — автоматически. В AWS это вообще мышом делается, накликал и будет анализировать логи/хидеры до скончания времён.

> Никакой автоматики я пока не вижу — всё придётся вручную сооружать, расставлять эти варнинги, майнтейнить, анализировать и... в итоге слать менеджерам письма, чтобы они на эти варнинги хоть как-то реагировали. Не проще ли сразу начать с писем?

О чем писать будешь, если тесты зелёные? Эй, манагеры, n*m зависимостей второго уровня чего то там поменяли, а вдруг у нас чтото не то?

P>> ну написано в там — пофиксили уязвимость в парсере. твои тесты зелёные. Дальше что?
·>Ты сценарий не с потолка бери, а начни с того, как тебе помогут варнинг-хедеры и каким образом они появятся _автоматически_ как ты обещаешь.

Я уже несколько раз показал. А ты еще ни разу. У тебя какая то магия — changelog сделает всё сам за себя.
Варнинги появляются как обычно, это разновидность ассертов/логирования, только рендерится и в респонс.
Итого — ты как решать будешь?

P>>С емейлами одна проблема — это в чистом виде человеческий фактора, например, потому что "устал, много писем, (не)прочитаю в понедельник"
P>>Я например регулярно сталкиваюсь с ситуацией , что какой либо менеджер не отвечает на письма. Думаешь если ему подкинуть еще сотню-другу емейлов, так он быстрее разгребется?
·>Ясно. Хедеры значит этот менеджер читает, а на емейлы сил уже не хватает.

Я пишу про мониторинг, а тебе мерещится "менеджер хидеры читает". Ты адекватен?
Как в твоем случае проблему обнаруживать будешь?

P>>Ну ок — реквест состоит из 100 переменных true-false, как долго будешь искать, какая же комбинация "та самая"?
·>Не дольше, чем искать для какой комбинации нужен варнинг.

Ты похоже не понял, что такое 2 в степени 100. Тестами ты гарантировано ничего такого не найдешь, т.к. прогон тестов закончится вместе с электричеством.
А вот на проде, скажем, если поставишь Warning.assert(precondontion, 'unexpected input') то все значения будут проходит эту проверку, и все подозрительные будут зарепортаны.