A delete button needs a server-side promise

Removing a result card from the browser is easy. Making a temporary audio file unavailable is a different engineering task.

I maintain Sonify alongside my earlier audio-tool work. Its conversion flow includes a delete action and temporary download links. Here is the contract I want that action to express, and the failure cases worth testing when building a similar tool.

Define what success means

A useful deletion result should describe server state. Hiding the card does not prove that processing stopped, that a temporary file was removed, or that an already issued download URL stopped working.

Separate the stages in your model: cancellation requested, cleanup in progress, and deletion complete. If cleanup fails, keep that failure observable and retryable. Do not show a completed deletion solely because the interface has stopped displaying the file.

Check ownership on every path

A random-looking job identifier is helpful, but it should not be the entire permission model. Status, download, streaming and delete paths all need to enforce the same ownership rule.

A practical test uses two independent sessions. Create a job in one session, then ask the other session to read, download or delete it. The second session should not gain access merely by knowing the job ID. Test the actual media routes as well as the status endpoint; protecting only the JSON response leaves a large gap.

Consider the work already in flight

A file may be converting or downloading when someone asks to delete it. Decide explicitly whether the operation cancels processing, prevents new transfers, interrupts current transfers, or uses a combination of those behaviors.

There is also a boundary the service cannot undo: bytes already saved to someone's device. Revoking server access is not remote deletion of a user's local copy. That distinction should shape both the implementation and the wording.

Verify outcomes, not just responses

An HTTP success response is one piece of evidence. Follow it with an attempted new download through the normal route. Confirm that the server no longer makes the deleted result available. For a server-side integration test, inspect temporary output cleanup as a separate assertion.

For a running job, cancellation tests should check the actual worker process or task lifecycle. A frontend state transition cannot establish that resource use has stopped.

Useful failure injection includes a temporary filesystem cleanup error, a repeated delete request, expiry during a download, and cancellation while encoding. Each exposes a different assumption about ordering and idempotence.

Keep expiry and manual deletion consistent

Temporary files need an automatic lifetime even when users never press Delete. Ideally, expiry and explicit deletion converge on the same cleanup rules, so one path does not leave files or links that the other would remove.

Sonify currently offers a 15-minute download window for prepared files and a manual delete action. It accepts individual permitted YouTube videos up to 30 minutes, with 128, 256 and 320 kbps MP3 output. These are current product boundaries, not a claim of universal source support or permanent storage.

A reliable delete button begins with a precise promise: what becomes unavailable, when that happens, and what evidence proves the action finished.

Disclosure: I maintain Sonify. This article was drafted by an AI assistant from the project's implementation and verification notes.