Dagster 1.13.26: dbt dependency changes and worker diagnostics

Dagster 1.13.26, published on October 9, 2026, changes how dagster-dbt installs its dbt dependencies, making environment composition an explicit upgrade concern. The release also fixes missing dbt materializations and improves failure diagnostics for pipeline operators. This is a stable release, pairing core 1.13.26 with libraries 0.29.26.

The full release notes are on the GitHub release page.

Models that completed with a no-op, reused, or warn status previously emitted no materialization. The asset silently stopped updating in Dagster, and downstream freshness checks and automation conditions never fired. Version 1.13.26 fixes that event handling. For pipelines driven by asset events, this closes a gap between a completed dbt model and the orchestration that should follow it.

The status boundary still matters. Dagster continues to treat partial success and skipped as failures. dbt marks dependents of a partially successful node as errored. Fusion also uses skipped for both a genuine operation with no work to do and a skip caused by an upstream failure. Treating every skipped result as successful would erase that distinction.

When checking this fix, inspect the materialization event and the downstream condition that consumes it. A completed model alone was not enough to establish that the orchestration path worked before this release. The relevant outcome is that Dagster records the event for the statuses covered by the fix.

fetch_column_metadata() and fetch_row_counts() now log a warning and emit events without metadata when running on the dbt Fusion engine. They also behave this way when dbt adapter initialization fails. Previously, those cases failed the step.

That changes what a successful step tells an operator. Execution can continue while column metadata or row counts are absent. A pipeline that depends on those fields for validation should check their presence separately; step success does not establish that collection succeeded.

The tradeoff is explicit. Metadata collection no longer stops the step in these cases, but consumers receive less information. During rollout, inspect the warnings alongside emitted events so missing metadata does not pass unnoticed into a downstream check or report.

A sensor tick requesting a run larger than the instance’s run size limit now fails with an explicit error. The error names the offending run requests. Previously, Dagster stored those requests in tick history. The useful change is the failure signal and its identification of the requests that exceeded the limit.

For an affected sensor, inspect the named requests against the configured instance limit. This release changes how Dagster reports the oversized request; it does not announce an increase to the limit. The error gives the operator a concrete request to investigate.

Run monitoring also includes the run worker’s debug information when it fails a started run because the worker failed. The notes give a Kubernetes OOMKilled termination reason as an example. That puts the worker’s reported reason into the run failure context, helping distinguish a terminated worker from a failure inside pipeline code. It adds diagnostic context; it does not change the worker’s memory requirements.

dagster-dbt no longer installs dbt-core automatically. Installations that require it must request the dagster-dbt[dbt-core] extra. Review dependency declarations that previously relied on the transitive installation before rebuilding the environment.

Keep dbt-core out of an environment containing dbt Fusion’s dbt PyPI package. Both claim the dbt import namespace and overwrite each other’s files, while pip reports no error. A successful package installation therefore does not prove that this combination is usable. Choose the intended dbt engine when defining the environment.