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

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

P>·>Это всё внутренняя кухня. Зачем это слать наружу, в каждом респонзе и засирать прод трафик-то? С учётом того, что консьюмеры это могут всё влёгкую игнорировать.
P>Внутренние консумеры не могут. А это бОльшая часть трафика. Внешние — тоже могут учитывать.
Почему не могут? И на вопрос "зачем" ты так и не ответил.

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

>> Никакой автоматики я пока не вижу — всё придётся вручную сооружать, расставлять эти варнинги, майнтейнить, анализировать и... в итоге слать менеджерам письма, чтобы они на эти варнинги хоть как-то реагировали. Не проще ли сразу начать с писем?
P>О чем писать будешь, если тесты зелёные? Эй, ребята, n*m зависимостей второго уровня чего то там поменяли, а вдруг у нас чтото не то?
У этих ребят должен быть свой мониторинг и процессы QA. Как ни странно.

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

P>Итого — ты как решать будешь?
Чтобы что-то решать, я должен понять задачу. Какую задачу решает логгирование в респонз и не может решить логирование в логи?

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

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