Dagster Runtime Fixes for Event Logs and Agents

Dagster is a Python data orchestration project, and this activity window is more about runtime reliability than a headline feature. Across 21 recent commits, the useful changes sit in event log writes, declarative automation for asset checks, Dagster Cloud agent recovery, and AWS EMR Serverless pipes.

The most operator relevant change is the event log index transaction update. The change groups event log index writes in transactions across the SQL event log storage path. That matters because asset event metadata is not just history. It feeds asset state, tags, checks, and the derived tables that make orchestration views usable at scale.

The commit text says the project is preparing to write more derived tables on event log writes. That is a useful signal. Once a scheduler or asset daemon depends on more derived state, partial index writes become harder to reason about. Grouping writes means the system has a cleaner unit of failure. Either the related index updates land together, or they do not.

This is still mostly internal plumbing. There is no public API to change here. The practical impact is that teams running large asset graphs should care about it anyway, because event log consistency is one of those quiet layers that only becomes visible when a backfill, materialization history, or check view starts lying.

Dagster also tightened declarative automation around asset checks. The partitioned asset check crash fix handles a case where a partitioned asset check can be requested without the asset it checks being materialized on the same tick. Before the fix, the mapping code tried to expand a check keyed subset into asset partition keys. That is the wrong shape, and it could fail the entire automation tick.

The important file here is python_modules/dagster/dagster/_core/definitions/automation_tick_evaluation_context.py, with coverage added in python_modules/dagster/dagster_tests/declarative_automation_tests/test_run_request_check_keys.py. The fix reads partition keys directly when the subset is keyed by an asset check. The asset keyed path still groups a check with its asset when both are requested in the same tick.

The related asset check key resolution fix points in the same direction. Asset checks are becoming a more active part of automated execution, not just a reporting layer after a run. That puts more pressure on key resolution, partition handling, and run request construction.

The Dagster Cloud side saw a few changes that matter for hybrid deployments. The recovery change for locations stuck after a failed refresh adds a periodic recovery check for a specific transient error path. When a location has a DagsterUserCodeUnreachableError, the watcher can refresh the code location instead of waiting for a manual reload to land on the affected webserver pod.

That scope is important. The change is not a blind retry loop for every load error. Syntax errors and other durable user code failures should not be retried forever. For operators, this is the right split: recover from unreachable user code when the network or process state clears, but do not hide broken code behind log noise.

The most recent activity also fixes the active agent heartbeat environment variable spelling in python_modules/dagster-cloud/dagster_cloud/workspace/user_code_launcher/user_code_launcher.py through the agent side change. The previous name used DAGSTER_CLOUD_ACTIVE_AGENT_HEARTBEAT_INVERAL; the corrected name is DAGSTER_CLOUD_ACTIVE_AGENT_HEARTBEAT_INTERVAL. Small typo, real operational effect if a team tried to tune heartbeat behavior.

The connectivity reproduction script is documentation, but it is useful documentation. It adds a script for hybrid deployments that opens concurrent connections to the Dagster+ API and sends a small GraphQL query through the same path the agent uses. The knobs are simple: NUM_TRIALS and CONCURRENCY.

That gives platform teams a way to compare failure rates before and after changing NAT, proxy, firewall, or TCP keepalive settings. It also moves the test from a vague network complaint to a repeatable check from the agent pod. That is the difference between chasing intermittent read timeouts in logs and having a concrete reproduction path.

The tradeoff is visible in the commit notes. The script reads a private _dagster_cloud_api_config attribute. That is acceptable for a troubleshooting snippet, but it is still an internal contract. If the attribute moves, the test may break even when the agent path is fine.

The AWS side has a contained but useful change for long running Spark work. The EMR Serverless dashboard refresh update adds dashboard_refresh_interval to python_modules/libraries/dagster-aws/dagster_aws/pipes/clients/emr_serverless.py. The default is 3300 seconds, or 55 minutes.

The old behavior refreshed Spark UI dashboard URLs every 900 seconds. EMR Serverless dashboard URLs are short lived, and requesting a new URL can invalidate the old one. A frequent refresh can interrupt a person trying to inspect logs during a run. The new parameter keeps the default closer to the one hour URL lifetime and still lets a team lower the interval when that fits its workflow.

The matching test coverage lands in python_modules/libraries/dagster-aws/dagster_aws_tests/pipes_tests/test_emr_serverless.py. For data teams using Dagster pipes with EMR Serverless, this is the kind of small default that can save real debugging time.

Watch the event log path first. Transaction grouping usually means more derived state is coming, and derived state tends to become part of the scheduler contract.

Asset checks are also moving deeper into automation. If a deployment uses partitioned checks with automation conditions, this set of fixes is worth picking up before adding more check driven execution.

For hybrid agents, keep a note of the corrected heartbeat variable and the new connectivity script. Both are practical tools for the kind of issue that only appears under real network pressure.