veza/veza-backend-api/cmd
senke 712a0568e3 feat(workers): hourly cleanup of orphan tracks stuck in processing
Upload flow: POST creates a track row with `status=processing` and
writes the file at `file_path`. If the uploader process dies (OOM,
SIGKILL during deploy, disk wipe) between row-create and status-update,
the row stays in `processing` forever with a `file_path` that doesn't
exist. The library UI shows a ghost track the user can never play,
never reach, and only partially delete.

New worker:

  * `jobs/cleanup_orphan_tracks.go` — `CleanupOrphanTracks` queries
    tracks with `status=processing AND created_at < NOW()-1h`, stats
    the `file_path`, and flips the row to `status=failed` with
    `status_message = "orphan cleanup: file missing on disk after >1h
    in processing"`. Never deletes; never touches present files or
    rows already in another state. Safe to run repeatedly.
  * `ScheduleOrphanTracksCleanup(db, logger)` runs once at boot and
    then every hour thereafter. Wired in `cmd/api/main.go` right after
    route setup so restarts trigger an immediate scan.
  * Threshold exported as `OrphanTrackAgeThreshold` constant so tests
    and future tuning don't need to edit the worker.

Tests: 5 cases in `cleanup_orphan_tracks_test.go`:
  - `_FlipsStuckMissingFile` happy path
  - `_LeavesFilePresent` (slow uploads must not be failed)
  - `_LeavesRecent` (below threshold)
  - `_IgnoresAlreadyFailed` (idempotent)
  - `_NilDatabaseIsNoop` (safety)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-16 14:57:24 +02:00
..
api feat(workers): hourly cleanup of orphan tracks stuck in processing 2026-04-16 14:57:24 +02:00
backup incus deployement fully implemented, Makefile updated and make fmt ran 2026-01-13 19:47:57 +01:00
generate-config-docs adding initial backend API (Go) 2025-12-03 20:29:37 +01:00
migrate_tool v0.9.4 2026-03-05 23:03:43 +01:00
tools style(backend): gofmt -w on 85 files (whitespace only) 2026-04-14 12:22:14 +02:00