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

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

P>·>Теперь последний шаг. В чём будет выражаться неигнорирование мониторинга? Ну допустим заметил какой-нибудь сисоп какой-то варнинг на дашбоарде. Дальше-то что?
P>Ты не в курсе как работает мониторинг и опсы?
В курсе. Теперь ты на мой вопрос ответь.

P>>>В случае с changlog ты вообще всю работу делаешь руками. А в данном случае ты просто добавил правило в мониторинг и всё.
P>·>Какую "всю"? Для справки, сhangelog — это лог сделанных изменений.
P>Именно.
P>1. надо прочитать, вникнуть в каждый тикет, посмотреть тамошние подробности
P>2. каждую строку проверить на предмет того, а не цепляет ли это вас
P>Повторить для всех n*m зависимостей
P>Прогнать тесты
P>Если они красные пофиксить
P>А если зеленые — а хер его знает. Тут мы выяснили, что ты плохо понимаешь, что такое 2^100 комбинаций, простейший случай
У тебя нет 2^100 комбинаций. В рассматриваемом случае у тебя есть ровно одна, ты же сам её написал. Вот она: Warning.assert(precondontion, 'unexpected input').
Если до тебя допёрло что можно написать именно этот Warning, значит ты с таким же успехом можешь создать джиру/послать емейл и добиться проверки|тестироваия|исправления этого данного precondontion. Заметать это под коврик хедеров, это лишь оттягивать удовольствие и вводить кучу никому не нужных слоёв, рискуя прод-инцидентами.

P>Как и несколько месяцев назад, ты как то не в курсе, что те же ассерты и тесты покрывают немного разные классы задач. Одни дискретные, другие — непрерывные. Для тебя, похоже, это пустой звук.
Провал ассерта это проблема твоя, а не твоих консьюмеров. Тебя она и должна беспокоить. Зачем это слать кому-то в хедерах — расскажи.

P>assert(deprecated) сработает вне зависимости от того, сколько у нас данных, 2^10 или 2^10^10.
Верно. Но если этот assert бабахнет, это твоя проблема, ты и обязан фиксить. Поэтому это должно быть в твоих логах. С какого боку тут хедеры?

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

P>А где я написал, что не надо мониторить логи?
Ты невнимательно читаешь вопрос. Я спрашиваю, почему именно хедеры надо? (а логи лишь _например_).

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

P> У них нет доступа к твоим логами.
Дай доступ. Настрой свой мониторинг и шли кому надо какие-нибудь сообщения в каком-либо виде — емейл, чаты, смски, джиры, етс, но не в хедерах каждого респонза. Терабайты съэкономишь.

P>Жесткий вариант — кидануть ошибку.
Правильный вариант в SIT-окружении, как минимум.

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