Spurious CustomKeyInConfigDeprecation on non-supported adapters: init_config never calls uses_adapter

[mikhail-zhadanov]

Expected behavior

The extension should match dbt's CLI: adapter-specific config validation (the jsonschema check behind CustomKeyInConfigDeprecation) should run only for the adapters dbt actually supports it on - bigquery, databricks, redshift, snowflake. On any other adapter (e.g. Exasol), the extension should not flag valid adapter-specific config keys.

Concretely: a project that parses cleanly with dbt parse / dbt build from the CLI should also parse cleanly in the extension, with no CustomKeyInConfigDeprecation warning for a config key the adapter declares as first-class (e.g. dbt-exasol's distribute_by_config).

Actual behavior

The extension emits a CustomKeyInConfigDeprecation warning for a valid adapter-specific config key that dbt's own CLI does not flag on the same project. Example: dbt-exasol declares distribute_by_config as a first-class config (read via config.get(...)), yet the extension reports it as an unknown/custom config key. Running dbt parse or dbt build from the CLI on the identical project produces no such warning.

Root cause: dbt gates this validation on the invocation context's adapter set:

# dbt/jsonschemas/jsonschemas.py
_JSONSCHEMA_SUPPORTED_ADAPTERS = {"bigquery", "databricks", "redshift", "snowflake"}

def _can_run_validations() -> bool:
    return get_invocation_context().adapter_types.issubset(_JSONSCHEMA_SUPPORTED_ADAPTERS)

dbt's CLI populates that set before parsing (dbt/cli/requires.py): get_invocation_context().uses_adapter(profile.credentials.type).

The extension parses via DbtProject.init_config() -> ManifestLoader().load() in @altimateai/dbt-integration's dbt_core_integration.py and never calls uses_adapter. So adapter_types stays an empty set, and set().issubset(anything) is vacuously True. _can_run_validations() therefore returns True for every adapter — including unsupported ones — causing the validator to run against adapters it was never meant to, and flagging their valid config keys.

Net effect: the warning fires on all non-supported adapters, not just Exasol.

Steps To Reproduce

1. Open a dbt project that uses a non-supported adapter — anything other than bigquery / databricks / redshift / snowflake (reproduced with dbt-exasol 1.10.6 on dbt-core 1.11.x).
2. Add a valid adapter-specific config to a model, e.g.:

   {{ config(materialized='incremental', distribute_by_config=['id']) }}
   

   (distribute_by_config is a first-class config declared by the dbt-exasol adapter.)
3. Let the dbt Power User extension parse the project (open the model / trigger a parse).
4. Observe: the extension reports CustomKeyInConfigDeprecation for distribute_by_config.
5. Run dbt parse (or dbt build) from the CLI on the same project, same environment.
6. Observe: the CLI produces no CustomKeyInConfigDeprecation warning.

The discrepancy between steps 4 and 6 is the bug.

Log output/Screenshots

Operating System

macOS

dbt version

dbt-core 1.11.11

dbt Adapter

dbt-exasol 1.10.6

dbt Power User version

0.61.6

Are you willing to submit PR?

• Yes I am willing to submit a PR!

[mikhail-zhadanov]

Happy to open a PR, but the relevant file (dbt_core_integration.py) was moved out of this repo into the @altimateai/dbt-integration package in #1697 ("use dbt integration library"), and that package has no public source/issue tracker. So I can't submit the fix where it actually lives. If you point me at the right repo, I'll send a PR.

The fix is a one-liner in DbtProject.init_config(), mirroring dbt's own CLI (dbt/cli/requires.py). Right after the config is built (self.config = RuntimeConfig.from_args(self.args)), register the active adapter on the invocation context so dbt's adapter-gated validation only runs on supported adapters:

if DBT_MAJOR_VER >= 1 and DBT_MINOR_VER >= 8:
    try:
        from dbt_common.context import get_invocation_context
        get_invocation_context().uses_adapter(self.config.credentials.type)
    except Exception:
        pass

set_invocation_context(os.environ) already runs earlier in the same >=1.8 branch, so the context exists at that point. This only narrows validation to {bigquery, databricks, redshift, snowflake}, exactly as the CLI does, no behavior change for those adapters, and the false positive disappears for everything else.

[anandgupta42]

We are already working on open-sourcing @altimateai/dbt-integration. It should be done in the next 2-3 days.