Announcing Dagster 1.6: Back to Black

Dagster UI upgrades

Dagster 1.6 sees some significant upgrades to the UI:

Dark mode for the Dagster UI: Let's start with the feature that gave this release it's name. By default, Dagster will match your system’s light or dark theme but you can adjust this in the user settings in the top right of the UI.

Dagster's asset lineage graph UI has had a facelift to make it easier to visualize and navigate large graphs

• Lineage now flows left-to-right instead of top-to-bottom.
• You can expand and collapse asset groups in the graph.
• A new left-hand sidebar provides a list of assets, organized by asset group and code location.
• You can right-click on assets or groups to filter or materialize them.
• You can filter by compute kind.

Report asset materializations from the UI: You can now record an asset materialization event without executing the code to materialize the asset. This is useful in cases where you overwrote data outside of Dagster, and you want Dagster to know about it and represent it in the UI. It’s also useful when you have a preexisting partitioned asset and start managing it with Dagster: you want Dagster to show the historical partitions as materialized instead of missing.

Backfill previews: When launching a backfill that covers assets with different partitions, you can now click “Preview” to see that partitions for each asset that will be covered by the backfill.

Triggered Run tracking: Runs triggered by either a sensor or a schedule now link to the tick that triggered them.

Sensor or schedule tick logs accessible by default: Previously, accessing this functionality required turning on a feature flag in user settings.

New APIs come out of "experimental" status

Speaking of "experimental" features becoming standard, "MaterializeResult, AssetSpec, and AssetDep APIs, introduced in Dagster 1.5, are now marked as "stable". They offer a more straightforward way of defining assets when you don’t want to use I/O managers. Thanks to the early users who helped us field-test this change.

Dagster Pipes

Dagster Pipes were introduced during last October's Launch Week and early adopters are seeing the potential in this new protocol for integrating and launching compute into remote execution environments. Based on early feedback from production users, we continue to invest in this important capability:

• Using Dagster Pipes with AWS Lambda is now much easier thanks to the AWS Lambda Pipes client –PipesLambdaClient See the guide for details.
• Report arbitrary messages between pipes processes and the orchestrating process – with report_custom_message and get_custom_messages.
• Termination forwarding – ensures that external processes terminate when the associated orchestration process is.

Contributors since 1.5.0:

We would like to thank all of the community members who have contributed to Dagster since the 1.5 release, building up to this week's 1.6 launch.

Daniel Gafni | xjhc | Mārtiņš Kalvāns | Ali Ebrahim | Tadas Malinauskas | Thomas | Tim Asp | BeigeOne | r1b | Cyberosa | Maxime Lagresle | Nicolai Lolansen | jlloyd-widen | Spartak | Jeanine Harb | Robert Pack | colton | Brett May | Oleg Butuzov | Tom Scholz | quantum-byte | maxfirman | Alexander VR | Sierrra | zyd14 | erik james mason | Brandon Peebles | Erik Kristofer Anderson | James Robinson | Nicolas Drebenstedt | Eugenio Contreras | Fábio | Alex Kan

---

We're always happy to hear your feedback, so please reach out to us! If you have any questions, ask them in the Dagster community Slack (join here!) or start a Github discussion. If you run into any bugs, let us know with a Github issue. And if you're interested in working with us, check out our open roles!

Follow us: