# Обработка всех предупреждений через warn-error

| require\_all\_warnings\_handled\_by\_warn\_error | dbt **v1 Latest** | dbt v1 |
| ------------------------------------------------ | ----------------- | ------ |
| Введён                                           | 2025.06           | 1.10.0 |
| Стабилизирован (по умолчанию → `true`)           | 2026.09           | 1.12.0 |
| Удалён                                           | —                 | —      |

<br />

Начиная с dbt v1.12, флаг `require_all_warnings_handled_by_warn_error` по умолчанию имеет значение `true`.

Когда этот флаг включён, все предупреждения, возникающие во время выполнения, направляются в обработчик `--warn-error` / `--warn-error-options`. Это обеспечивает единообразное поведение при преобразовании предупреждений в ошибки или их подавлении. Когда флаг имеет значение `false`, обработчик обрабатывает лишь некоторые предупреждения, а остальные могут его обходить.

В проектах, использующих `--warn-error` (или `--warn-error-options='{"error":"all"}'`), сборки могут завершаться с ошибкой из-за предупреждений, которые ранее игнорировались.

## Влияние

Это затрагивает только проекты, использующие `warn_error: true` или `--warn-error`, — такие настройки часто применяются в CI или в производственных заданиях dbt platform, настроенных на строгий режим. Проекты без `--warn-error` не затрагиваются.

Примеры предупреждений, которые для пользователей с `warn_error: true` теперь приводят к ошибке, а не просто записываются в журнал:

* `JinjaLogWarning` — возникает, когда типы столбцов объявлены для несуществующих столбцов seed
* `WarnStateTargetEqual` — возникает, когда для каталогов `--state` и `--target` указан один и тот же путь
* `SelectExcludeIgnoredWithSelectorWarning` — возникает, когда устаревший флаг `--selector` используется вместе с `--select` или `--exclude`
* `RunResultWarningMessage` — возникает, когда тест или модель возвращает статус `WARN`
* Различные предупреждения на уровне адаптеров, которые ранее не обрабатывались через `--warn-error`

 Рекомендуемые действия

Если задание, использующее `warn_error: true` или `--warn-error`, завершается с ошибкой `EventCompilationError` на этапе разбора или выполнения из-за класса событий, который ранее появлялся только в виде строки журнала, вы можете подавить отдельные предупреждения с помощью `warn_error_options`:

dbt\_project.yml

```yaml
flags:
  warn_error_options:
    silence:
      - JinjaLogWarning
      - WarnStateTargetEqual
      - RunResultWarningMessage
      - SelectExcludeIgnoredWithSelectorWarning
```

Также можно использовать список `warn`, чтобы оставить определённые события предупреждениями, даже если `--warn-error` в противном случае преобразовал бы их в ошибки.

Чтобы отключить это поведение, установите для флага значение `false`:

dbt\_project.yml

```yaml
flags:
  require_all_warnings_handled_by_warn_error: false
```