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

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

P>Они нужны в момент, как и логи, во время запуска в тч на проде.
P>Например — выявить, если какаято из 2^100 комбинаций дала подозрительный результат.
Выявлять комбинации ассерты не могут в принципе. Ассерт может лишь выявить комбинацию, прописанную в precondition. Или у тебя в коде 2^100 ассертов?!

P>>>·>У тебя нет 2^100 комбинаций.
P>>>Есть. Типичный реквест содержит куда больше информации.
P>·>И что? Мы говорим о конкретном warning, который появится в хедере. Который проверяет вполне конкретную информацию по конкретному алгоритму. Т.е. ровно одна комбинация.
P>Он проверяет свойство результата, например, или свойство входа. У какой из 2^100 комбинаций эти свойства будут нарушены?
У той, которая прописана в precondition.

P>>>Мы снова говорим о том, что ты не понимаешь роль ассертов. Ассерт используется там, где джира-емейл-тестирование неприменимо. Это механизм того же рода, что и логи.
P>·>Я о роли ассертов и тестов не рассуждал и вообще ничего не говорил. В данном контексте это неважно.
P>Наоборот, именно это и важно.
Важно для чего? Вопрос был — почему ассерт должен добавлять именно хедер?

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

P>>>И снова ты пишешь о том, что не в курсе проблемы которую решают ассерты.
P>·>Мне пофиг какие проблемы решают ассерты. Это к разговору не относится. Я пытаюсь из тебя вытянуть какие проблемы решает хедер.
P>Ты вроде выяснил — административные, разделяет зоны ответственности."херли вы пользуетесь старой схемой, если год назад мы вам дали новую"
Мы вроде выяснили, что хедер никак не может решать административные проблемы. Игнорировать хедеры гораздо проще, чем, например, емейлы и т.п.

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

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

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

P>·>2. Мы вроде о внутренних консьюмерах говорили.
P>В данном случае это скорее внешние консумеры. Коммуникация то отсутствует, разные подразделения, может оказаться так, что и доступа друг к другу не имеют вовсе. Т.е. разницы со внешними консумерами никакой. Пока менеджмент не договорится, должно быть решение.
Значит и их мониторинг вам неподконтролен. И какие-то из 1-7 шагов будут благополучно потеряны и забыты практически наверняка.

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

Прикольно, оказывается в http есть хедер Warning. И, кто бы мог подумать, deprectated.