pub async fn execute<H, F, G, C>(
plan: &Plan,
manifest: &mut Manifest,
albums: &mut BTreeMap<String, AlbumArt>,
playlists: &mut BTreeMap<String, PlaylistState>,
desired: &[Desired],
ports: Ports<'_, H, F, G, C>,
opts: &ExecOptions,
) -> ExecOutcomeExpand description
Apply plan to disk, updating manifest and albums in place, and return
the outcome.
desired carries the per-clip metadata and art hashes plus the source modes
that decide the preserve marker; it is indexed
by clip id (and by target path, for renames) so each written entry records
the right hashes and protection. albums is the album-art store, keyed by
stable root id: folder-art writes and deletes record their state there rather
than on the per-clip manifest. ports bundles the authenticated client and
the network, disk, transcode, and backoff ports. A single clip’s failure
never aborts the run, except an auth failure or a full disk, which stop it
with RunStatus::AuthAborted or RunStatus::DiskFull.
The audio-producing actions (Download and
Reformat) run concurrently, bounded by
ExecOptions::concurrency: their slow parts (WAV render, CDN download,
transcode, tag) overlap while the order-sensitive Suno API calls are
serialised behind an async mutex over the shared SunoClient, keeping the
adaptive limiter and JWT refresh correct. The remaining actions (retag,
rename, delete, and artifact writes/deletes) then run serially in plan order.
The outcome is deterministic regardless of completion order: concurrent audio results are committed to the manifest in plan-index order, so the same plan always yields the same manifest and counts whatever the concurrency level. A per-clip failure is recorded and the run continues; only an auth failure or a full disk aborts, and it does so promptly by stopping further audio work.