A music generation request can outlive the browser that submitted it. The useful record is a durable job with its input, current attempt and any remote request identity saved together. When a browser reconnects, it should be able to show that record without starting another generation.
Fone MusicFlow provides a concrete source example, with an important evidence limit. Its promotional demonstration uses the fixed Dream Walk audio, cover and lyrics. The inspected worker code also contains non-mock provider branches and recovery handling. That establishes implementation structure, but this article does not establish that a real provider account has completed a generation or that its output meets a quality target.
Give each attempt a boundary
The worker claims a queued job by changing its status to processing under a database transaction. A claim that changes no row exits without generating anything. This gives competing workers a shared decision point. A second worker seeing the same queue message should find that the job has already moved.
An execution token identifies the particular worker run. The attempt stores its request snapshot, response state and heartbeat. Before saving a result, the worker checks that the job is still processing with the same attempt and execution token. That check matters after recovery, when an older process may still finish even though another process has taken responsibility.
Inputs also need a stable meaning. The inspected attempt snapshot combines music configuration with the requested song settings. Saving those values avoids describing an old result using settings that an operator changed later. A retry should make its relationship to the original attempt visible, including whether it resumes a remote request or starts a new one.
| Saved record | Question it answers | Review requirement |
|---|---|---|
| Job and attempt number | Which submission does this belong to? | Preserve across browser refresh |
| Execution token | Which worker may commit a result? | Reject stale completions |
| Provider response state | Has the remote service accepted work? | Inspect before resubmission |
| Input snapshot | Which settings produced this attempt? | Keep with the result version |
| Review and publication records | May the result be shown publicly? | Keep separate from generation success |
Recover the request you already have
The current worker refreshes a heartbeat during processing and looks for interrupted work after a two-minute stale interval. Its recovery decision depends on the provider and saved remote state. Some work can return to the queue with the same attempt; other cases become explicit unknown-result failures. These are source behaviors, not measured recovery guarantees.
That distinction should survive in the interface. A known rejection can offer an edited resubmission. An unknown result needs investigation of the original request because it may have produced an output or incurred a charge. Repeatedly pressing a generic retry button can hide that uncertainty and make later reconciliation harder.
For a new provider integration, agree on how the adapter submits, polls and retrieves results before connecting the UI. Record the provider's documented retry semantics. A transport timeout alone cannot establish whether a remote service accepted the request. The downloadable mock exercise uses a saved request identity to make this decision inspectable without calling an external model.
A generated file still needs a release decision
On a successful attempt, the inspected worker writes a generation result and a song version, then creates separate review and publication records. That separation gives the product a place to decide whether the audio is suitable, whether the metadata describes it accurately and whether the intended use is covered.
The mock path checks the fixture audio hash and copies the same bundled media into the attempt output. It records the provider as mock and marks the source as a demo. The lyrics remain unsynchronized rather than receiving invented word timings. Retain those labels in review screens and exports so a fixed sample cannot be mistaken for fresh output from the submitted prompt.
A real adapter introduces additional acceptance work. The team needs to check unavailable output URLs, interrupted downloads and an output that arrives after the local attempt stops. Rights for audio, lyrics and artwork also need their own review. Neither a completed queue record nor a successful file download establishes permission to publish a track commercially.
Use the music job review worksheet to record these decisions. It includes an independent synthetic adapter exercise whose six automated checks passed. Those checks cover lost acceptance responses, resumed polling, checkpoint restoration and the review boundary. They operate on a fixed text label with no external model calls. The product review worksheet remains unexecuted, and real provider behavior still requires separate validation. For a project discussion, bring the desired creation flow, provider choice and publication responsibilities to Fone MusicFlow.
