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

P>>При том, что трафик после такого гатевея уже внутренний

НС>Да. Я тебе больше скажу — у меня там целая пачка кастомных хидеров бегает. Но вот варнинги там точно не нужны.

А разве я говорю что надо всенепременно именно варнинг добавить? Если ты научился протаскивать капабилити с одним кастомным хидером, то какие проблемы будут с другой капабилити ?

P>>2. И вот ты прочел changelog, проверил все что мог, тебя тесты зелёные. Твои действия? Что конкретно ты будешь предпринимать
P>> в такой вот ситуации? Есть хороший пример, что бы не абстрактно рассуждать? ты то не надеешься на варнинги, как с проблемой будешь работать?

НС>Вопрос непонятен. О какой проблеме речь?

Вот так обычно и отвечают, когда указываешь, что changelog какая то хрень.

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

НС>Еще раз — 2 уровень заголовки тоже не отслеживают (если конечно ты не будешь эти заголовки пропогейтить по всей цепочке, что совсем уж дичь если сопоставить с исходной задачей).

Зачем пропагейтить? Делегируешь процессинг другому компоненту, он от себя будет кидать, что бы ничего не пропагейтить.

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

Теоретически. Когда ты всё контролируешь, и ничего никому не делегируешь, то можно и заранее дать ответ. Но таких случаев не так уж и много. Варнинг можно интерпретировать мониторингом как на этой стороне, так и на той. И это может быть дешевле чем мастырить архитектуру поверх всего.

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

НС>Расскажи как.

Я уже рассказал и тебе, и точке.