[Regression] `upload-multitrack` returns empty `200` and creates jobs with empty `audio_path` (playback `404`)

[T012m3n7oR]

What the issue is

POST /api/v1/transcription/upload-multitrack accepts uploads (200 OK), but the created multi-track job is not playable and API clients may fail to parse the response:

• Clients receive an empty 200 response body where docs indicate a TranscriptionJob JSON payload.
• The created job later fails audio playback via GET /api/v1/transcription/{id}/audio with 404.
• Server debug logs show the job has no audio_path (Audio path: '').

Why this is a problem

• Breaks API contract for typed clients expecting JSON response (TranscriptionJob) on success.
• Multi-track upload appears successful to users, but playback fails in UI (Unable to load audio stream.).
• Job remains in a non-usable state for downstream workflows, making multi-track behavior unreliable.

Environment

• Image: ghcr.io/rishikanthc/scriberr-cuda:latest
• Resolved digest: sha256:3babe419f7eb543a69de59071867aa8e6c7415dfb652683f39c4b355513a70e9
• Deployment: Docker Compose
• Observed: 2026-05-04

Expected behavior

After successful multi-track upload:

1. API returns 200 with valid TranscriptionJob JSON body.
2. Job has a playable source (audio_path fallback or merged_audio_path after merge).
3. GET /api/v1/transcription/{id}/audio returns streamable audio (not 404 due to empty path).

Actual behavior

1. Upload returns 200 but may have empty body.
2. Job is created and listed.
3. Audio endpoint fails:
   • Debug output: Audio path: ''
   • Response: 404 Audio file path not found

Evidence (logs)

Upload accepted

INFO  13:38:19 POST /api/v1/transcription/upload-multitrack 200 265.94ms

Playback failure for created job

DEBUG: GetAudioFile for job d5293504-0f71-461d-9f08-7287c0124564
DEBUG: Job status: uploaded
DEBUG: Audio path: ''
DEBUG: Audio path is empty
INFO  13:49:30 GET /api/v1/transcription/d5293504-0f71-461d-9f08-7287c0124564/audio 404 0.68ms

Reproduction steps

1. Upload multiple tracks to POST /api/v1/transcription/upload-multitrack.
2. Open the created job in the UI.
3. Attempt playback.
4. Observe Unable to load audio stream in frontend and Audio path: '' in backend logs.

Suspected regression points (from git history)

• 99031c5 (major refactor): UploadMultiTrack flow changed from tracks path (with fallback AudioPath and processing trigger) to newer path that no longer guarantees playable source population.
• bcb22af (docs: update swagger documentation for delta sync API): appears to remove c.JSON(http.StatusOK, job) in UploadMultiTrack, causing empty 200 response body.

Suggested fix direction

1. Restore JSON success response in UploadMultiTrack:
   • c.JSON(http.StatusOK, job)
2. Ensure multi-track uploads become playable:
   • set a valid audio_path fallback, and/or
   • guarantee merged_audio_path generation and availability before playback.
3. Ensure lifecycle transitions beyond uploaded as intended for multi-track processing.
4. Add/expand tests to assert:
   • non-empty JSON body on successful multi-track upload,
   • non-empty playable path and successful /audio fetch post-upload/processing.

[T012m3n7oR]

I was intending to use Scriberr for the same use case as #181, although I wrote my own bot before finding craig. As is, I would have to upload everyone's audio separately and combine manually. This is possible - was just hoping that I could use what you already had.

The current state of the codebase looks like you may have been moving away from the .aup file, and I'm willing to complete the work as I could use the functionality - just need a little guidance on what your intended outcome is.