Dagster 1.13.18 - Retry Health And Snowflake dbt Fixes

Dagster 1.13.18, paired with library release 0.29.18, was published on August 14, 2026. Its main operational change is more precise asset health reporting while automatic retries are pending. Failed partitions in that state now produce a warning instead of marking the asset as degraded.

The full release notes and downloads are on the GitHub release page.

An asset can have failed partitions without being in a settled failure state. In this release, an asset reports warning health when every failed partition is waiting for an automatic retry. The previous degraded result did not distinguish that retry window from a failure that was no longer moving through recovery.

The asset health popover now states that a retry is pending. Alert notifications carry the same context. This gives an operator two useful facts at once: a partition failed, and Dagster still has an automatic recovery attempt queued.

The condition is narrow: every failed partition must be awaiting an automatic retry. A mixed asset, where only some failed partitions have pending retries, does not meet the condition described in the release notes. That boundary matters when interpreting a warning across a partitioned asset.

The release notes describe a reporting change, not a change to retry scheduling or execution. Teams that route pages from degraded asset health should still review their rules. Depending on local alert filters, the same pending retry state will now enter the warning path rather than the degraded path.

The SnowflakeDbtProjectComponent now accepts the defs_state configuration field. Dagster+ deployments can use that field to opt into versioned state storage. The option matters when definitions need an explicit stored version instead of relying only on the state available to the running deployment.

The same component also corrects how its observation sensor classifies dbt runs. A run started by Dagster could previously be reported as externally triggered. That was an attribution error in the observed event stream, even though the underlying run had been initiated by Dagster.

Correct origin data matters for operational review. It separates work launched through Dagster from work launched outside it, which keeps observation records and any downstream analysis based on those records aligned with the actual initiator.

Another SnowflakeDbtProjectComponent fix covers dbt builds that include models outside the selected Dagster asset subset. The component previously raised an error in that situation. Version 1.13.18 removes that failure case, so extra models produced by the dbt build do not invalidate the selected asset operation.

Core configuration handling also fixes defaults on discriminated unions. A config field typed as a discriminated union could declare a default value, but Dagster ignored it. The fix restores that default path. Pipelines that worked around the bug by always passing an explicit value can now test whether the declared default is sufficient.

These are narrow correctness changes. The release notes contain no breaking change or migration procedure, but the health severity change can affect alert routing and is worth checking before rollout.