Description

When a DAG with an approval step is resumed after being approved, subsequent container steps fail because registry_auths and step env configurations are lost during the resume.

Steps to reproduce

1. Create a DAG with registry_auths (either in the DAG file or in base.yaml) and an approval step between two container steps:

registry_auths:
  my-registry.example.com:
    username: ${REGISTRY_USER}
    password: ${REGISTRY_PASSWORD}

steps:
  - name: step1
    container:
      image: my-registry.example.com/my-image
      pull_policy: always
      startup: command
      command: [echo, "step1"]
      env:
        - MY_VAR=hello

  - name: approve
    approval:
      prompt: "Continue?"
    command: "echo ok"

  - name: step2
    container:
      image: my-registry.example.com/my-image
      pull_policy: always
      startup: command
      command: [echo, "step2"]
      env:
        - MY_VAR=hello

2. Start the DAG — step1 succeeds (image pull works, env vars available)
3. Approve the approve step
4. step2 fails with unauthorized: 401 Unauthorized or no basic auth credentials

Expected behavior

step2 should pull the image and run with the same registry_auths and env as step1.

Actual behavior

After approval, the DAG is resumed via an internal retry subprocess. This subprocess rebuilds the DAG from the stored YAML but appears to lose:

• registry_auths configuration (image pull fails)
• env variables defined on steps (application errors about missing env vars)

This happens whether registry_auths is defined in the DAG file directly or in base.yaml.

Control test

The same DAG without the approval step works perfectly — both container steps pull and execute successfully.

Environment

• Dagu version: 2.2.4-12c2e53
• Docker Engine on Linux (amd64)
• Private Docker registry with basic auth