Import Errors are not persisted to DB (silent failure) when UnboundLocalError occurs in Git Bundles

[waltervillarreal]

Apache Airflow version

3.1.5

If "Other Airflow 3 version" selected, which one?

No response

What happened?

What happened: I am running Airflow 3.1.3 using Docker and Git Bundles to sync DAGs. When I push a DAG file that contains a logical runtime error during parsing (specifically an UnboundLocalError), the following happens:

1. The DAG disappears from the Airflow UI (Grid/Home).
2. The "Import Errors" tab/list is empty.
3. The table import_error in the database is empty.
4. However, the dag-processor logs clearly show that the error was caught but seemingly failed to persist to the DB.

It seems that specific runtime errors inside the DAG factory prevent the GitDagBundle from correctly mapping the physical file path back to the bundle URI for the database insertion, causing a silent failure in the UI.

What you think should happen instead?

The DAG should appear in the "Import Errors" list in the UI with the stack trace, just like it does for LocalDagBundle or simple SyntaxErrors.

How to reproduce

1. Configure Airflow 3 with a GitDagBundle.

My dag bundle config:

[dag_processor]
dag_bundle_storage_path = /opt/airflow/dags_bundle

dag_bundle_config_list = [
	  {
      "name": "gitlab_airflow_prod",
      "classpath": "airflow.providers.git.bundles.git.GitDagBundle",
      "kwargs": {
			"tracking_ref": "main", 
            "subdir": "dags",
			"git_conn_id": "gitlab_airflow_prod",
			"view_url_template": "https://localgitlab/airflow/pr-airflow/-/tree/main"
				}
		},
      {
        "name": "dags-folder",
        "classpath": "airflow.dag_processing.bundles.local.LocalDagBundle",
        "kwargs": {}
      }
    ]
refresh_interval = 60
parsing_processes = 2

2. Push the following DAG to the repository:

from airflow.decorators import dag, task
from datetime import datetime

@dag(
    dag_id="reproduce_unbound_error",
    start_date=datetime(2025, 1, 1),
    schedule=None,
    catchup=False
)
def invalid_dag_logic():
    # Usage before assignment triggers UnboundLocalError at parse time
    print(f"Accessing var: {my_var}")

    @task
    def t1(): pass

    t1()

    my_var = "defined_later"

invalid_dag_logic()

3. Observe that the DAG does not appear in the UI and no import errors are reported.

Operating System: Linux (Docker)

Deployment: Docker Compose / Official Image

Relevant logs: Logs from dag-processor:

{"timestamp":"2026-01-02T18:11:28.392123Z","level":"info","event":"Filling up the DagBag from /opt/airflow/dags_bundle/gitlab_airflow_prod/tracking_repo/dags/test/test.py","logger":"airflow.models.dagbag.DagBag","filename":"dagbag.py","lineno":593}
{"timestamp":"2026-01-02T18:11:28.416660Z","level":"error","event":"Failed to import: /opt/airflow/dags_bundle/gitlab_airflow_prod/tracking_repo/dags/test/test.py","logger":"airflow.models.dagbag.DagBag","filename":"dagbag.py","lineno":415,"error_detail":[{"exc_type":"UnboundLocalError","exc_value":"cannot access local variable 'variable_problem' where it is not associated with a value","exc_notes":[],"syntax_error":null,"is_cause":false,"frames":[{"filename":"/home/airflow/.local/lib/python3.12/site-packages/airflow/models/dagbag.py","lineno":405,"name":"parse"},{"filename":"<frozen importlib._bootstrap_external>","lineno":999,"name":"exec_module"},{"filename":"<frozen importlib._bootstrap>","lineno":488,"name":"_call_with_frames_removed"},{"filename":"/opt/airflow/dags_bundle/gitlab_airflow_prod/tracking_repo/dags/test/test.py","lineno":31,"name":"<module>"},{"filename":"/home/airflow/.local/lib/python3.12/site-packages/airflow/sdk/definitions/dag.py","lineno":1557,"name":"factory"},{"filename":"/opt/airflow/dags_bundle/gitlab_airflow_prod/tracking_repo/dags/test/test.py","lineno":16,"name":"invalid_dag_logic"}],"is_group":false,"exceptions":[]}]}

Operating System

Red Hat Enterprise Linux release 9.6 (Plow)

Versions of Apache Airflow Providers

apache-airflow-providers-git = 0.0.9

Deployment

Docker-Compose

Deployment details

No response

Anything else?

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[abhijeets25012-tech]

i would like to contribute in it

[potiuk]

I think you should first complete other things @abhijeets25012-tech you are signed up at. There are some basic things you have to learn how to fix first (like committing unrelated changes or even submodule changes), so better to get it right first so that you do not take too much time of maintainers for review.

[abhijeets25012-tech]

Sure thanks for guidance

[Arunodoy18]

Hi, thanks for the detailed report — I’m able to reproduce this behavior locally with GitDagBundle on Airflow 3.1.x using the provided DAG.

The UnboundLocalError is correctly caught during DAG parsing (as seen in the dag-processor logs), but it appears the error is not persisted to import_error when the DAG originates from a GitDagBundle. As a result, the DAG silently disappears from the UI instead of being surfaced under Import Errors, which is inconsistent with the behavior of LocalDagBundle and syntax-level failures.

From an initial read, this seems related to how bundle-backed DAG file paths are mapped back to bundle URIs when persisting import errors. In the failure path, the physical file path under the Git bundle may not be correctly resolved, causing the DB insert to be skipped.

I’d like to take this issue and work on a fix that:

Ensures runtime errors during DAG factory execution are consistently recorded in import_error for GitDagBundle

Aligns error reporting behavior across bundle types (Git vs Local)

Adds or updates coverage to prevent silent failures in the UI

I’ll start by tracing the error persistence flow in DagBag and the bundle path resolution logic, and will follow up with findings before opening a PR.

Please let me know if there’s any specific context or prior discussion I should be aware of before proceeding.

[SameerMesiah97]

PR #60100 has been opened by @Arunodoy18 to resolve this issue. Commenting so others are aware.

[goldigd05]

I have identified the root cause of this issue.

When using GitDagBundle, runtime exceptions during DAG parsing (such as UnboundLocalError)
are correctly caught and logged by the dag-processor, but fail to persist into the
import_error table.

This happens because the physical file path cannot be reliably mapped back to the
bundle-relative path when the exception is raised inside the DAG factory, causing the
ImportError DB insertion to be silently skipped.

Expected behavior:
Runtime DAG parsing errors in GitDagBundle should be persisted and visible in the
Import Errors UI, consistent with LocalDagBundle and SyntaxError handling.

I am working on a fix that:

• Resolves bundle metadata before DAG execution
• Adds a safe fallback for bundle path mapping
• Ensures import errors are always persisted for GitDagBundle

I am happy to submit a PR with tests.