Dagster 1.13.9 - Hierarchical Asset Groups and Scheduler Fixes

   |   3 minute read   |   Using 631 words

Dagster 1.13.9 shipped on 11 June 2026 as a stable release (core 1.13.9, libraries 0.29.9). The headline change is hierarchical asset groups: you can use / in group names and select whole subtrees with wildcards in the asset graph.

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

Hierarchical asset groups and selection filters

Asset group names can now include / separators to build nested groups. A group like marketing/ads shows up as a nested node in the asset graph instead of a flat label with a slash in it.

Selection syntax follows the hierarchy. Wildcards work on group paths, so group:"marketing/*" picks every asset under the marketing prefix. That matters when large codebases split domains across folders and you want one selection string for a whole subtree.

A new is: filter joins the asset selection and search syntax. You can target assets by type with expressions like is:external or is:materializable. Useful when a job should only touch materializable assets or when you need to audit external dependencies separately from internal tables.

On the UI side, filtering assets in the lineage view now offers a “Save selection” button tied to the selection input. The recent updates timeline on asset pages got a redesign as well. Small changes, but they reduce friction when operators iterate on saved views.

Helm replicas, Cloud uploads, and dg project env parsing

Kubernetes operators running Dagster via Helm get replicaCount on user code deployments. Multiple replicas of the same deployment share a consistent gRPC server ID, which stops spurious code location reloads that used to happen when scaling out.

For Dagster Cloud, uploads through S3 presigned URLs now retry on transient HTTP 500 responses. That covers code location snapshots, serverless I/O manager objects, compute logs, and PEX files. Network blips during deploy should fail less often.

Local dg project setup picks up a fix in .env parsing. DG_PROJECT_PYTHON_EXECUTABLE is now read through python-dotenv, so export KEY=value lines, quoted values, and trailing comments behave the way most developers expect.

The dagster-dlt integration adds partitions_def and backfill_policy support on DltLoadCollectionComponent. Pipelines that already partition dlt loads can wire those defs without custom wrappers.

Bugfixes that affect schedules, config, and sensors

Several fixes target day to day reliability rather than new surface area.

YAML config no longer turns date shaped strings into datetime objects. Values like "2021-10-30" stay strings, which avoids subtle type mismatches in ops that expect plain text partition keys or config fields.

Run failure sensors now receive the originating step error when a run fails due to a step failure. Before this release, that context could be missing on the sensor side, which made alert routing and triage harder than it needed to be.

Cron schedules with hour or day constraints were ticking as if they ran all day. A schedule like */15 9-16 * * 1-5 could inflate partition counts and produce oversized backfills. The scheduler now respects those constraints correctly.

Storage shutdown had a deadlock risk when event log watchers on Postgres or MySQL shut down while a watch callback was unsubscribing at the same time. That race is closed.

TemplatedSqlComponent generates a unique default op name from its template now, so multiple components without an explicit execution name no longer collide at graph build time.

UI fixes include the backfill step status dialog “View runs” action opening the runs dialog, and the asset partitions page resetting the focused partition when it falls outside the selected range.

Documentation

The dagster-dbt guide gained a “Blue/green deployments” section under patterns and best practices. It documents the clone then swap workflow for dbt deployments. No runtime change, but worth a read if you run dbt models through Dagster and want a safer promotion path.

Where to get it



denis256 at denis256.dev