Problem

Reschedule selected is broken for DAG runs that were originally created from an inline YAML spec, especially when the run was enqueued through the API.

These runs persist the original DAG snapshot, including the YAML definition, in DAG run data. However, rescheduling still behaves like a fresh name/path-based load. For inline-spec runs, that can point back to a temporary file that no longer exists, causing the reschedule to fail with errors such as failed to open file ... no such file or directory.

As a result, a run that was successfully created from inline YAML cannot be reliably rescheduled from the UI or API, even though the original YAML is already stored with the run.

Expected Behavior

Rescheduling a DAG run created from an inline spec should use the persisted DAG snapshot from the original run data, including the stored YAML, instead of requiring the original file path to still exist.

If the original run was created successfully from inline YAML, Reschedule selected should create a new run from that same stored definition and preserve the original runtime parameters.

Example

name: test-params-flag
params:
  - KEY=value
steps:
  - name: print
    command: echo "${KEY}"

A DAG run created by submitting this YAML inline should still be reschedulable later, even after the temporary source file used during the original submission has been removed.

Motivation

This unblocks a core workflow for API- and UI-driven execution where DAGs are submitted as inline specs instead of permanent files on disk.

Today, users can enqueue and run inline definitions, but they cannot reliably use Reschedule selected afterward. That makes reruns fragile, breaks operational recovery for failed inline runs, and undermines a workflow that Dagu already has enough persisted data to support correctly.

Tests

• PR must include integration tests under intg package.