denis256 notes and projects

Dagster 1.13.10 was published on June 18, 2026, with core package version 1.13.10 and library package version 0.29.10. This release is not marked as a prerelease, and its most important fix is for stale latest materialization state after assets or partitions are wiped. For operators, that is the kind of bug that can make a healthy asset graph look wrong, or worse, make a wrong one look healthy.

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

Asset wipes now report cleaner latest state

The headline fix is around DagsterInstance.get_latest_materialization_event and get_asset_records. Before this release, those APIs could return a stale materialization from before an asset wipe once a new run targeting the asset started, or once an observation was reported.

That matters because latest materialization state is not just a nice detail in the UI. It feeds how engineers reason about asset freshness, run history, and whether a wipe actually cleared the state they expected to clear. If old state leaks back into that view, an operator can spend time chasing behavior that is already gone.

The notes also call out the analogous Dagster+ case for partition wipes. Wiping partitions could leave the wiped partition materialization as the asset’s latest materialization. Dagster 1.13.10 corrects that state handling, so a wipe should mean the latest view reflects the post wipe world.

Backfills are less likely to stall

Dagster 1.13.10 fixes an asset backfill case where the backfill could stop emitting runs but never complete. The trigger was a mismatch between partition definitions: one asset included certain dates while an upstream or downstream asset excluded them.

That is a practical production fix. Partition calendars are often not identical across assets. Some datasets skip holidays, late source windows, or business day rules. A backfill that silently stops while still looking active is expensive to debug because nothing is visibly failing.

With this release, that stuck state should be avoided for the case described in the notes. Teams running mixed partition definitions should still inspect backfill results, but this removes one sharp edge from date based asset recovery.

Cron partition counts get faster

There is also a performance fix for assets partitioned by cron schedules that use explicit minute lists. The example in the notes is 0,30 * * * *, which should behave like an every thirty minute cadence similar to */30.

Before the fix, explicit minute lists could make partition count computation much slower than the equivalent step syntax. That sort of slowdown is annoying because the schedule is semantically small, but the system pays a larger cost just because of how the expression is written.

Dagster 1.13.10 makes that case faster. Operators with cron partitioned assets do not need to rewrite schedules just to avoid the slower path covered by this bug fix.

Backfill pages and text heavy views should feel lighter

Large deployments get another backfill related improvement. Loading backfills for a partition set previously fetched and deserialized every backfill in the deployment on each request. In a deployment with many historical backfills, that is a lot of work for a narrow query.

The release changes that path so partition set backfill loading performs better at scale. This is mainly an operator experience fix: less wasted request time when looking at a partition set that should not need the full deployment history.

The UI also gets a separate rendering fix. A regression made views with truncated text, including the asset catalog, render slowly. Dagster 1.13.10 addresses that regression, so catalog style pages with many truncated labels should be less sluggish.

Where to get it

• Release page: Dagster 1.13.10 release
• Repository: Dagster repository
• Tag: 1.13.10