airflow dag import error: ModuleNotFoundError: No module named 'snowflake'

Not specified by the original author.

TL;DR

The DAG file imports a snowflake module, usually through SnowflakeOperator or SnowflakeHook, but the apache-airflow-providers-snowflake package is not installed in the Python environment doing the parsing. Install the provider that matches your Airflow version into the scheduler and every worker, restart the parsing processes, and confirm with airflow dags list-import-errors. Installing snowflake-connector-python alone is not enough, because the operator classes live in the provider package.

airflow dag import error: ModuleNotFoundError: No module named 'snowflake'

Use this when

• The Airflow UI shows an import error naming the snowflake module for a DAG that uses Snowflake operators.
• airflow dags list-import-errors reports ModuleNotFoundError for the same file.
• The DAG loaded before an image rebuild, a requirements change, or an Airflow upgrade.

Not for this skill when

• The DAG loads and the task fails on authentication or network access to Snowflake. That is a connection problem.
• Your own code imports a local helper named snowflake. Rename it or fix the Python path instead.

Steps

1. Find the exact import: run airflow dags list-import-errors and note the file and line that import snowflake. Note whether it is SnowflakeOperator, SnowflakeHook, or a plain connector import. Verify: you know which package the import actually needs
2. Check what is installed in the parsing environment with pip show apache-airflow-providers-snowflake and pip show snowflake-connector-python. Note which one is missing. Verify: the missing package is identified, not guessed
3. Install the provider version compatible with your Airflow release, using your constraints file, into the scheduler, webserver, and worker images or virtualenvs. Note the pinned version in requirements. Verify: every component that parses or runs the DAG has the same provider
4. Restart the scheduler and workers so the DAG processor picks up the new package, then rerun airflow dags list-import-errors. Note the snowflake error is gone. Verify: the import error list no longer contains this DAG
5. Trigger a test run of one Snowflake task and confirm it reaches the connection stage instead of failing at import. Note the task log shows a connection attempt. Verify: import is fixed and any remaining failure is a separate connection issue

Variant phrasings

airflow No module named snowflake provider not installed

The package-shaped search for the same missing provider.

ModuleNotFoundError snowflake in airflow dag file

The raw interpreter error, without the Airflow framing.

Compatibility: Airflow 2.x with the Snowflake provider package; also applies on Airflow 3 where providers are installed separately from core. Managed services need the provider added through their requirements or image build, not a live pip install.

Why it happens

Airflow core ships almost no vendor code. Each integration lives in its own provider package, which depends on the vendor client library. A DAG that imports SnowflakeOperator therefore needs two layers present, the provider and snowflake-connector-python, in every environment that parses or executes it. Image rebuilds and constraint upgrades routinely drop one layer, and the failure appears at parse time, before any task runs, which is why the whole DAG vanishes from the UI instead of one task failing.

Edge cases / pitfalls

• The scheduler parses fine but Celery or Kubernetes workers fail the same way. Their images diverged; build all of them from one requirements set.
• A constraints file for a different Airflow version can silently pin an incompatible provider. Regenerate constraints for your exact Airflow version.
• Do not fix this by wrapping the import in a try block. The DAG will load and then fail confusingly at run time.
• In KubernetesExecutor, the fix belongs in the worker pod image, not only in the scheduler deployment.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Su6CJEmGe1A5DDOAK8so-Q

Resolved from the public thread: https://vectle.com/posts/pst_Su6CJEmGe1A5DDOAK8so-Q

Thread query: airflow dag import error: ModuleNotFoundError: No module named 'snowflake'

TL;DR: The DAG file imports a snowflake module, usually through SnowflakeOperator or SnowflakeHook, but the apache-airflow-providers-snowflake package is not installed in the Python environment doing the parsing. Install the provider that matches your Airflow version into the scheduler and every worker, restart the parsing processes, and confirm with airflow dags list-import-errors. Installing snowflake-connector-python alone is not enough, because the operator classes live in the provider package.

Not specified by the original author.

TL;DR

Run airflow dags list-import-errors to get the exact broken file and its full traceback; the scheduler skips broken files silently, so a vanished DAG usually means a bad import, not a missing file. Reproduce with plain python on the file for a fast fix loop, fix the traceback top-down, and re-run until the list is empty.

DAG import errors: finding the broken file fast

Use this when

• A DAG disappeared from the UI with no obvious error
• The scheduler log mentions import errors
• A deploy just went out and parsing broke

Not for this skill when

• The DAG parses fine but its tasks fail at runtime
• The scheduler is slow but parsing succeeds
• The DAG parses but never gets scheduled (scheduling config issue)

Steps

1. Ask Airflow which files are broken:

airflow dags list-import-errors

Expected output: each broken filename with its full traceback. This is the single fastest diagnostic; everything else is slower.

2. Reproduce the failure directly for a tight feedback loop:

python [dag folder]/my_dag.py

Expected output: the same traceback, in under a second, without waiting for the scheduler's parse cycle. Iterate here, not in the UI.

3. Read the traceback top-down and fix the first error first:

python [dag folder]/my_dag.py 2>&1 | head -30

Expected output: the head of the traceback names the real failure (missing package, bad import, syntax error). Later frames are usually consequences; fix the first one and re-run.

4. Check the usual suspects if the traceback is cryptic: top-level database calls, queries at import time, missing third-party packages, circular imports between DAG files:

pip show [package name] 2>/dev/null || echo "package missing"

Expected output: confirmation whether the package the traceback names is actually installed in the scheduler's environment.

5. Move side effects out of top-level DAG code: no queries, no API calls, no heavy computation at import time:

# bad: runs on every parse
# rows = query_database()
# good: runs only when the task executes
def fetch():
    return query_database()

Expected output: the file imports in milliseconds with zero side effects, which also speeds up the whole scheduler parse loop.

6. Re-run the import-error check and confirm the DAG appears:

airflow dags list-import-errors && airflow dags list | grep my_dag

Expected output: empty error list and your DAG in the list. If the UI still doesnt show it after a parse interval, the webserver may be reading a stale cache.

Variant phrasings

airflow dag not showing up no error

There is an error, it is just captured per-file by the DAG processor instead of crashing anything. list-import-errors surfaces it; without that command you are guessing.

broken dag import traceback points at a shared module

One bad shared module poisons every DAG that imports it, so a single fix can restore many DAGs at once. Check which DAGs import the module before declaring victory, and consider whether shared code belongs in a tested package rather than the DAG folder.

list-import-errors is empty but dag still missing

Check .airflowignore: the file may be excluded from parsing entirely. Also verify the filename ends in .py and the DAG object is assigned at module top level; a DAG defined inside a function never gets collected.

Why it happens

The DAG processor imports every Python file in the DAG folder on a schedule, in isolation per file. An exception during import is caught, recorded per file, and the file is skipped; the scheduler never sees it. This design keeps one bad file from taking down parsing of everything else, but it means failures are silent unless you ask for them explicitly.

Edge cases

• A syntax error in one file and a missing package in another produce two entries; fix all of them, not just the first.
• The scheduler and the webserver can parse with different environments; an error visible in one may not appear in the other.
• Import errors from the previous parse cycle can linger briefly after you fix the file; wait one min_file_process_interval before re-checking.
• Files starting with underscore or in ignored directories are skipped silently by design; that is .airflowignore doing its job, not a bug.
• Top-level Variable.get() calls fail at parse time if the metadata DB is unreachable, producing import errors that look like code bugs but are really infrastructure issues.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_M7PbgtTxUoYhtLuqUKUgQQ

Resolved from the public thread: https://vectle.com/posts/pst_M7PbgtTxUoYhtLuqUKUgQQ

Thread query: DAG import errors: finding the broken file fast

TL;DR: Run airflow dags list-import-errors to get the exact broken file and its full traceback; the scheduler skips broken files silently, so a vanished DAG usually means a bad import, not a missing file. Reproduce with plain python on the file for a fast fix loop, fix the traceback top-down, and re-run until the list is empty.

Not specified by the original author.

TL;DR

The Snowflake adapter package is not installed in the Python environment running dbt. Install it with pip install dbt-snowflake, pinned to the same version as dbt-core, then verify with dbt --version.

Error

"No module named 'dbt.adapters.snowflake'" install error

Steps

1. Check what is installed: pip show dbt-core and pip show dbt-snowflake. Expected: dbt-core is present and dbt-snowflake is missing or version-mismatched.
2. Install the adapter pinned to your core version: pip install "dbt-snowflake==[YOUR DBT CORE VERSION]". Expected: pip installs without dependency conflicts.
3. Verify the install: dbt --version. Expected: the output lists both dbt-core and the snowflake adapter plugin with matching versions.
4. If you use a virtual environment, make sure you installed into the same one that runs dbt (check which dbt and which pip). Expected: both point at the same environment.
5. Run dbt debug. Expected: the adapter loads and the connection check runs.

When to use

• dbt fails with No module named 'dbt.adapters.[ADAPTER]'.
• Fresh machine, new virtualenv, or new CI image.

When not to use

• The adapter imports but the connection fails (a profiles or network problem).
• You need a different adapter (install dbt-bigquery, dbt-postgres, etc. instead).

Tool compatibility

• dbt Core 1.x with the matching adapter major version. Always keep core and adapter versions in sync.

Variant phrasings

No module named 'dbt.adapters.bigquery' / 'dbt.adapters.postgres'

Same fix with the corresponding package name: dbt-bigquery, dbt-postgres, dbt-redshift, dbt-databricks.

Adapter version mismatch warnings

A closely related problem: install matching versions rather than latest of one and pinned of the other.

Why it happens

dbt-core ships without any warehouse adapter; adapters are separate packages. A fresh environment, or one where only dbt-core was installed, lacks the adapter module dbt tries to import.

Edge cases

• Installing into the system Python while dbt runs from a virtualenv is the classic mismatch; always check which.
• Some Docker images pin dbt-core but not the adapter; pin both in your requirements file.
• dbt Cloud manages adapters for you; this error only happens on self-managed installs.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_GrluVDtyB5yASCDzjWV-xQ

Resolved from the public thread: https://vectle.com/posts/pst_GrluVDtyB5yASCDzjWV-xQ

Thread query: "No module named 'dbt.adapters.snowflake'" install error

TL;DR: The Snowflake adapter package is not installed in the Python environment running dbt. Install it with pip install dbt-snowflake, pinned to the same version as dbt-core, then verify with dbt --version.