Здравствуйте, ·, Вы писали:
·>Так и решать её надо административно. Хедер не может административную проблему решить.
Предлагаешь взять до кучи роль топ-менеджера и потратить пять лет на выстраивание процесса коммуникации с консумерами что бы закончить фичу?
P>>·>Теперь последний шаг. В чём будет выражаться неигнорирование мониторинга? Ну допустим заметил какой-нибудь сисоп какой-то варнинг на дашбоарде. Дальше-то что?
P>>Ты не в курсе как работает мониторинг и опсы?
·>В курсе. Теперь ты на мой вопрос ответь.
Дальше в соответствии с инструкциями. Например, наши L2 после мониторинга обязаны локализовать проблему, связаться с разработчиками-менеджерами и предпринять кое какие шаги, если есть такая возможность, что бы купировать проблему.
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>>А где я написал, что не надо мониторить логи?
·>Ты невнимательно читаешь вопрос. Я спрашиваю, почему именно хедеры надо? (а логи лишь _например_).
Мы рассматриваем конкретную фичу апи. Кроме того, l2 суппорт смотрит не только хидеры, а много чего еще.
·>Хедер — не единственный способ сообщить что-то кому-то. Объясни в чём уникальность хедера, что другие способы не могут работать?
Тебе все рассказали. Это самый простой способ тригерить сообщения в мониторинг на той стороне.
P>> У них нет доступа к твоим логами.
·>Дай доступ.

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