Decaf Blog Data pipelines, open-source tooling, reverse engineering, and systems notes

Dagster 1.13.12 - Automation and dbt Fixes

4 min read

Dagster 1.13.12 was published on July 2, 2026, with fixes that matter most to automated orchestration, dbt event conversion, and code location recovery. The main operational change is a fix for partitioned asset checks that could halt an automation tick when the target asset was not materialized in the same tick. This core release is paired with library version 0.29.12 and is not marked as a prerelease.

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

Automation ticks and partitioned checks

The most important scheduler fix in Dagster 1.13.12 is for partitioned asset checks with their own automation condition. Before this release, a check requested on a tick that did not also materialize its target asset could raise a CheckError. That failure could stop the entire automation tick.

For teams using asset checks as part of data quality gates, that is the kind of bug that turns a local mismatch into a broader orchestration failure. The release note does not describe a migration step, but the behavior matters for partitioned pipelines where checks and asset materializations do not always share the same cadence.

The fix is narrow, which is useful. It does not change the asset check model in the notes. It addresses the tick failure path that made one requested check capable of interrupting unrelated automated work.

Code locations recover after transient gRPC failures

Dagster 1.13.12 also fixes a code location refresh problem that could leave a location stuck in an error state after a transient gRPC failure. The notes call out Kubernetes rolling deployments as a common case. That is a realistic failure mode for platform teams that update user code locations while the control plane is still serving requests.

The change is in the gRPC server watcher. It now periodically retries refresh for locations whose load error is DagsterUserCodeUnreachableError. That gives the system a route back to a healthy state after the user code server becomes reachable again.

This is not a broad rewrite of deployment semantics. It is a recovery loop for a specific unreachable user code error. For operators, the practical value is fewer manual nudges after brief network or pod availability gaps during rollout.

dbt events, EMR Serverless, and large runs

The dagster-dbt library gets a compatibility fix for run result conversion. Dagster could raise a KeyError on failures when converting dbt run results to Dagster events if that key was missing. The notes mention dbt Fusion as an example of a run that can omit it.

That is a small change, but it sits on a common integration boundary. Event conversion needs to tolerate shape differences in upstream tool output. A missing optional key should not stop Dagster from producing events for the run.

For AWS users, dagster-aws adds a dashboard_refresh_interval parameter to PipesEMRServerlessClient. The default was also increased so Spark UI URLs are no longer invalidated too early during a run. This is mostly about observability during EMR Serverless work, but it matters when engineers need to inspect Spark execution while the job is still active.

The UI change is more bounded. The runs feed now fetches a limited preview of large asset and asset check selections, then loads full lists on demand. That should reduce load for runs that target many assets or checks. There is also a layout fix for long pool names and dialogs with many pools. Useful, but less central to pipeline correctness than the scheduler and integration fixes above.

Watch list for operators

There are no breaking changes or migration steps in the release notes. The items to validate are operational.

Check automation policies that run partitioned asset checks separately from materializations. Watch code location refresh behavior during the next Kubernetes rolling deployment. If you use dbt Fusion or any dbt output that may omit failures, confirm that event conversion no longer raises the old KeyError.

For EMR Serverless, review any local assumptions around PipesEMRServerlessClient dashboard timing. The new dashboard_refresh_interval parameter gives teams an explicit control when the default is not a good match for run duration.

Where to get it