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

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

P>>>Они нужны в момент, как и логи, во время запуска в тч на проде.
P>>>Например — выявить, если какаято из 2^100 комбинаций дала подозрительный результат.
P>·>Выявлять комбинации ассерты не могут в принципе. Ассерт может лишь выявить комбинацию, прописанную в precondition. Или у тебя в коде 2^100 ассертов?!
P>Могут, еще как. Это их основное предназначение. Сам же пишешь — выявить комбинацию прописаную в условии. Только не precondition, а postcondintion, и даже инвариант. И не сама комбинация прописывает, а её признаки. Условие ровно одно — свойства входа или результата.
Под precondition я имею в виду идентификатор из твоего кода: Warning.assert(precondontion, 'unexpected input'). Тебя опять куда-то унесло в оффтопик.

P>Например — контрольная сумма. Гыгы. Не сходится — с реквестом вероятно чтото не то. Логируем, выставляем варнинг и возвращаем респонс.
Такую херню надо просто реджектить без вопросов. Если вы не реджектите, то ясно понятно почему у вас такая беда с тестированием и контролем качества. Системы как бы работают, но никто толком не понимает как и почему.

P>>>Он проверяет свойство результата, например, или свойство входа. У какой из 2^100 комбинаций эти свойства будут нарушены?
P>·>У той, которая прописана в precondition.
P>В прекондишн прописано только условие. На этапе разработки ты эту комбинацию не знаешь.
Если ты эту комбинацию не знаешь, ты не сможешь написать Warning.assert(precondontion, 'unexpected input').

P>>>Наоборот, именно это и важно.
P>·>Важно для чего? Вопрос был — почему ассерт должен добавлять именно хедер?
P>Надо же как то задетектить некорректный вызов. Есть простой вариант — deprecated вызов. Если все сходится к этому — это очень даже легко. Есть и более сложные, например, процессинг выдал варнинги, которых быть не должно, и в хидере x-варнинг будет ссылка на урл этих варнингов.
Перечитай вопрос внимательно. Почему именно хедер? Например, пусть ваш мониторинг аггрится на ERROR в логах и шлёт емейлы кому положено, напрямую. Зачем эти промежуточные слои через rest, чужой мониторинг, чужой L2 и т.п.?

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

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

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

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

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

P>>>В данном случае это скорее внешние консумеры. Коммуникация то отсутствует, разные подразделения, может оказаться так, что и доступа друг к другу не имеют вовсе. Т.е. разницы со внешними консумерами никакой. Пока менеджмент не договорится, должно быть решение.
P>·>Значит и их мониторинг вам неподконтролен. И какие-то из 1-7 шагов будут благополучно потеряны и забыты практически наверняка.
P>Забавно, что ты так и не показал, что будет в твоем случае. В основном эти 1-7 шагов благополучно работают, и именно потому, что легко автоматизируются и не требуют давать взятку менеджеру по security.
Да тоже самое. Оптимум — после 0го шага сразу 8й. Ну или 7й, может быть. Шаги 1-6 не нужны вообще.

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

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

P>·>Прикольно, оказывается в http есть хедер Warning. И, кто бы мог подумать, deprectated.
P>Для браузера в этом смысла не много, он всё равно ничего исправить не сможет. А вот в конкретном приложении на такой хидер можно навесить дополнительные капабилити, например, счетчик варнингов и тротлинг по мере роста, логирование на вызывающей стороне, И это всё без изменения кода сервисов.
Для этого не нужен хедер отправлять консьюмерам. Т.к. это всё навешивается у провайдера, а не у консьюмеров. Опять на ходу тему меняешь.