[Bug] alias ignored and cache invalidation issue when using partial parse

[ghjklw]

Is this a new bug in dbt-core?

• I believe this is a new bug in dbt-core
• I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior

We have experienced that very rarely, and seemingly randomly, dbt parse or any other dbt command would generate a manifest looking where the alias defined for the model is ignored. This wouldn't impact all models, only a very limited number (often only one).

For example, with a model like this one:

version: 1

models:
  - name: model_name
    config:
      alias: model_alias

The manifest would look like this:

"model.package.model_name": {
      "name": "model_name",
      "resource_type": "model",
      "package_name": "package",
      "unique_id": "model.package.model_name",
      "alias": "model_name",
      "config": {
        "enabled": true,
        "alias": null,
        ...
      },
      ...

This would also impact all other dbt commands: dbt run would generate a table using the name instead of the alias. If we try to run a downstream model without rerunning the impacted model, it would fail because the reference would resolve with the wrong table name.

We found no way to trigger/reproduce this bug, but when it happened, we are able to reliably observe it by "re-using" the problematic partial_parse.msgpack file. This happens quite rarely: we observe it about every other week across a team of 5 developers each running multiple local environments and across 4 development/production environment running Airflow/Cosmos.

Expected Behavior

Using the example above, I would expect the manifest to look like:

"model.package.model_name": {
      "name": "model_name",
      "resource_type": "model",
      "package_name": "package",
      "unique_id": "model.package.model_name",
      "alias": "model_alias",
      "config": {
        "enabled": true,
        "alias": "model_alias",
        ...
      },
      ...

Steps To Reproduce

I can't provide complete reproduction steps as I have not found a way to trigger the bug yet, but once it has happened, I ran the following testing steps, assuming target/bug contains a failing partial_parse.msgpack and target/ok contains a working partial_parse.msgpack:

1. Run both dbt parse --target-path target/ok and dbt parse --target-path target/bug
2. Confirm that both target/bug/manifest.json and target/ok/manifest.json have been updated (based on metadata.generated_at), but bug is incorrect (config.alias is null) while ok is as expected.
3. Run mv target/bug/partial_parse.msgpack target/bug/partial_parse.msgpack.bug, and then again dbt parse --target-path target/bug
4. Confirm that target/bug/manifest.json has been updated and is now as expected.
5. Run rm target/bug/partial_parse.msgpack, mv target/bug/partial_parse.msgpack.bug target/bug/partial_parse.msgpack and dbt parse --target-path target/bug
6. Confirm that target/bug/manifest.json has been updated again and that the error has reappeared.

Relevant log output

No error message

Environment

- OS: Debian Bookworm (12)
- Python: 3.12.8
- dbt: 1.8.8

Which database adapter are you using with dbt?

other (mention it in "Additional Context"), spark

Additional Context

Adapter: dbt-databricks 1.8.7