The production host runs cPanel, which already owns ports 80/443 for
other sites on the box -- there's no Traefik there. docker-compose.prod.yml
now binds the api container to 127.0.0.1:8000 only; the host's own
Apache/LiteSpeed (via cPanel) reverse-proxies api.amdbs.net to it and
terminates TLS itself (AutoSSL). Dropped the external traefik-public
network requirement and Traefik labels entirely.
Also corrected a separate latent inaccuracy while touching this: a bare
`docker compose up` (not `docker stack deploy`) never actually honored
deploy.replicas -- docs now say so and point at `--scale` instead of
implying free multi-replica scaling that was never really happening.
README's Production deployment section rewritten with concrete steps:
Cloudflare DNS record, cPanel subdomain + reverse proxy, then compose up.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
cached_response() had no write-side invalidation, so re-ingesting an
entity kept serving its pre-ingestion cached response for up to
CACHE_DEFAULT_TTL. Found live: re-ingesting a movie to test the new
company-logo field still showed logo_path: None because the sliding
5-minute cache from earlier testing never expired.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Section 10: every image API responses reference has pointed straight
at TMDb's CDN since day one -- Aurora never actually downloaded or
served artwork itself, despite storing dimensions/checksum/local_path
columns for exactly that. Closes the gap:
- is_primary was declared on the Artwork model but never actually set
anywhere -- every row defaulted to False. Now the normalizer marks
the one image each provider designates as *the* image for an entity
(TMDb's poster_path/backdrop_path/profile_path) as primary,
distinct from the dozens of alternates also ingested, including
correctly marking an existing row primary (not inserting a
duplicate) when that image already appears in the alternates list.
- app/services/artwork/: an ArtworkStorage interface with a
LocalDiskStorage implementation (checksum-named files, single-host
deployment via a Docker volume shared between api and worker -- see
docs/architecture.md for the S3/R2 upgrade path), and a download
pipeline with content-type validation, a size cap, and path-traversal
protection.
- After movie/series/person ingestion succeeds, tasks.py cascades one
download_artwork_task per primary artwork id via arq's ctx['redis']
(same fan-out pattern as the season cascade) -- fire-and-forget, not
tracked in ingestion_jobs, since a failed image cache is a
known-safe fallback to the provider URL, not a user-facing failure.
- app/main.py serves MEDIA_ROOT at MEDIA_URL_PREFIX; local_path is
preferred over original_url once set (already-existing fallback
logic in app/services/common.py:artwork_url, now actually exercised).
Also fixes a real interaction bug this surfaced: every ingestion
pipeline deleted and recreated all of an entity's Artwork rows on each
re-sync, which would have silently wiped local_path/checksum on every
re-ingestion, forcing a full re-download every time and defeating the
point of caching locally at all. app/repositories/polymorphic.py's new
sync_artwork upserts by provider_asset_id (TMDb's stable per-image
path) instead, preserving downloaded copies across re-sync, and
replaces three near-identical delete+recreate helpers that used to
live separately in movie_ingestion.py, series_ingestion.py, and
person_ingestion.py.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
arq only auto-retries a job on its own Retry exception (or
CancelledError) -- never on an arbitrary exception a task raises.
_run_ingestion caught failures, recorded them via mark_job_failed
(which sets ingestion_jobs.status to "retrying" when attempts hasn't
hit max_attempts), and then just re-raised the original exception --
which arq treats as a terminal failure. The DB said "retrying"
forever; nothing ever put the job back on the queue.
Confirmed live: cascading Better Call Saul's 6 seasons hit the
get_or_create race fixed in the previous commit on 4 of them, and the
worker's own shutdown summary showed "4 failed, 0 retries" -- every
one of those was permanently lost despite max_attempts=5 suggesting
otherwise.
_run_ingestion now raises arq.Retry (capped exponential backoff) when
mark_job_failed left the job in RETRYING state, so arq actually
requeues it; only once attempts are exhausted does the original
exception propagate as a genuine terminal failure.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
