21 Commits

Include renames

Author	SHA1	Message	Date
NixReaperandClaude Sonnet 5	f1ac072794	Add GET /collections browse endpoint; fix embedded collection poster_path ... Completes browse/discover across all five entity types: movies, series, people, companies, and now collections. No filter (no categorical field like company_type exists for a collection) -- just page/page_size, always alphabetical by name. While adding poster_path to CollectionBriefOut for the browse listing, found the same class of bug fixed earlier for company logo_path: movie_service's embedded `collection` field never looked up its poster artwork either, so it stayed null even after ingest_collection populated one. Fixed alongside since it's the same schema field this feature was already touching. Also removed PageMeta from schemas/common.py -- scaffolding from early spec work that was never actually wired into any endpoint; all five browse endpoints shipped this session use a flat page/page_size/ total_results/total_pages shape instead. Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-05 20:08:26 -05:00
NixReaperandClaude Sonnet 5	92b0f4e077	Add GET /companies browse/discover endpoint ... Completes the browse/discover set across all four entity types. Companies have no popularity or date field, so unlike movies/series/ people there's no sort_by choice -- always alphabetical by name. Filters are company_type (validated against the enum) and country (a plain ISO 3166-1 code comparison, nothing to validate). build_company_summary refactored to share row-to-summary logic with the new list path, same pattern used for movies/series/people. Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-05 19:08:14 -05:00
NixReaperandClaude Sonnet 5	6aa9f0b840	Add GET /people browse/discover endpoint ... Extends the browse/discover pattern already built for movies/series to the fourth major entity type. No genre/year/status equivalent for people -- known_for_department is the one categorical filter that actually means something for a cast/crew list, and sort_by is just popularity (default) or name. No invalid-filter case either: unlike genre/status, known_for_department is a plain string compared directly, nothing to parse or validate. build_person_summary refactored to share row-to-summary logic with the new list path, same pattern used for movies/series/companies. Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-05 10:32:16 -05:00
NixReaperandClaude Sonnet 5	74adcf77bc	Add series endpoint parity: /credits, /images, /videos ... Movies have separate /credits, /images, /videos sub-endpoints; series only had /seasons. Adds the matching three for series, reusing the same cast/crew/creators three-way split series detail already does (extracted into _split_series_credits so both share it). Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-05 09:52:08 -05:00
NixReaperandClaude Sonnet 5	6956bf7406	Add movies/series filmography to company detail ... GET /companies/{id} showed only the company's own info. Adds movies and series lists (any role: production, distribution, network), ordered by release/first-air date, read straight off the existing movie_companies/series_companies junction rows -- no separate sync needed since those only ever exist as a side effect of ingesting the movie or series itself. Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-05 09:34:31 -05:00
NixReaperandClaude Sonnet 5	606d2532c4	Add per-episode breakdown to guest-star filmography credits ... FilmographyCreditOut already aggregated a guest star's episode appearances into one row per series with an episode_count, but never exposed which episodes those were even though the individual episode Credit rows exist in the database. Adds an `episodes` list (season/ episode number, title, air date, sorted chronologically) alongside the existing count -- closes a known limitation tracked in docs/api.md. Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-05 09:19:52 -05:00
NixReaperandClaude Sonnet 5	20f5e82d1b	Add GET /movies and GET /series browse/discover endpoints ... The complement to /search for browsing without a query: paginated, filterable (genre, year, status) and sortable (popularity, release/air date, rating, title) listings. Offset-based pagination rather than the Aurora ID cursor scheme, since sorting by popularity/rating/date doesn't line up with creation-order cursors. Total count is computed via a window function in the same query as the page of results, avoiding a second round trip per request. An invalid filter (malformed genre id, unknown status) is a 422 via a per-service InvalidMovieFilterError/InvalidSeriesFilterError, caught before any DB query runs. build_movie_summary/build_series_summary refactored to share their row-to-summary logic with the new list path, avoiding a redundant get_by_id lookup when the row is already in hand. Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-05 09:01:11 -05:00
NixReaperandClaude Sonnet 5	892f78016c	Add collection/franchise ingestion ... Collections were bare stubs (name only) lazily created the moment a movie's belongs_to_collection reference was seen. Adds a real ingest_collection pipeline: TMDb's /collection/{id} for overview and poster/backdrop artwork, plus ordered CollectionMovie membership -- linking only movies already ingested into Aurora, the same never-fabricate-a-stub rule movie recommendations already follow. get_or_create_collection now refreshes name/overview on an existing stub instead of only creating, guarded so a bare movie-stub call (overview=None) never clobbers real data a full ingestion already filled in. New POST /api/v1/admin/ingest/collection endpoint and ingest_collection_task; GET /api/v1/collections/{id} needed no changes since its read path (collection_service.py) already assembled the full detail shape. Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-05 08:37:27 -05:00
NixReaperandClaude Sonnet 5	4af4ba40ef	Add GET /movies/{id}/recommendations ... Ingestion already stored movie_recommendations edges from TMDb's recommendations list (linking only to movies already ingested into Aurora, per the never-fabricate-a-stub rule), but nothing exposed them. Adds the repository lookup, service assembly, and route to read them back in ranked order. Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-05 08:16:18 -05:00
NixReaperandClaude Sonnet 5	73488a0d80	Fix movie/series API responses never surfacing company logo_path ... movie_service.get_movie_detail() hardcoded companies[].logo_path = None instead of looking up the company's logo artwork, and tv_service's networks[]/companies[] never set logo_path at all -- both just built CompanyBriefOut without the artwork lookup that company_service.py (and _season_brief for posters) already does correctly. Ingestion and storage were working the whole time; the API layer just never read the result. Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-05 08:01:56 -05:00
NixReaperandClaude Sonnet 5	2138d4afc3	Invalidate movie/series/person detail cache on re-ingestion ... 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]>	2026-09-05 07:56:00 -05:00
NixReaperandClaude Sonnet 5	c03a75989d	Ingest and self-host company/network logos ... CompanyBriefOut.logo_path and CompanyDetailOut.logo_path have existed in the API schemas since Core 0.1's first pass, but nothing ever actually populated them -- TMDb's production_companies/networks entries carry a logo_path field that the normalizer simply never read, so every response has silently returned null there. - NormalizedCompanyRef now captures logo_path from both movie production_companies and series networks/production_companies. - normalizer.company_logo_artwork() builds the single-image artwork entry for it (a company has exactly one logo ingested, so it's always is_primary) -- centralized there rather than duplicated in both ingestion modules, matching how movie/series artwork URLs are already built in one place. - movie_ingestion.py and series_ingestion.py sync it via the same sync_artwork() the rest of section 10's self-hosting already uses, so it gets the same re-ingestion-safe upsert behavior for free. - tasks.py cascades a download_artwork_task per referenced company after movie/series ingestion, same fan-out pattern as movie/series/season/person artwork. Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-05 07:46:30 -05:00
NixReaperandClaude Sonnet 5	7c4bfe6cf4	Fix sync_artwork clobbering is_primary via duplicate list entries ... TMDb's images.posters/backdrops alternates commonly include the *same* image as the top-level poster_path/backdrop_path -- so normalize_movie legitimately produces the same provider_asset_id twice in one artwork_list: once from the top-level field (is_primary=True), once from the general alternates loop (is_primary=False, the default). sync_artwork matched both occurrences to the same existing DB row by provider_asset_id and did a plain overwrite each time, so whichever occurrence it processed last won -- the non-primary duplicate always came second in list order, so it silently un-set is_primary right after the first occurrence had just set it. Caught by re-ingesting The Matrix on a devbox with the artwork download feature live: the movie ingested successfully, but zero download jobs were ever enqueued because get_primary_artwork_ids found nothing marked is_primary -- the flag had been clobbered back to false immediately after being set. Fixed by resetting is_primary on all existing rows up front (so a provider dropping its "primary" pick on an image actually clears, not just adds) and accumulating with OR within the batch instead of a plain overwrite, so any primary occurrence in one sync sticks regardless of processing order. Also dedupes brand-new rows within the same batch the same way, closing the equivalent bug for images that don't have an existing row yet. Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-05 07:30:40 -05:00
NixReaperandClaude Sonnet 5	fef914db36	Add artwork self-hosting: local-disk download worker + storage ... 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]>	2026-09-05 03:26:28 -05:00
NixReaperandClaude Sonnet 5	cd4dd98adb	Make failed ingestion jobs actually retry, not just say "retrying" ... 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]>	2026-09-05 02:31:43 -05:00
NixReaperandClaude Sonnet 5	dd3ff9764b	Fix race condition in get_or_create_* under concurrent ingestion ... Every get_or_create_* helper (genre, keyword, language, country, company, collection, person) followed check-then-act: look up by natural key, insert if missing. That was safe as long as nothing ingested concurrently for overlapping data -- which stopped being true the moment ingest_series_task could cascade season ingestion (include_seasons), since arq runs multiple queued jobs concurrently. Two seasons of the same series sharing a guest star, crew member, or company can now race to create it: both see "not found", both try to INSERT, and the loser hits a unique-constraint violation instead of finding the winner's row. Reproduced live: cascading Better Call Saul (60059) with include_seasons crashed a season job with "duplicate key value violates unique constraint uq_external_id_source" on a recurring guest actor shared across two seasons ingesting at the same time. _create_or_recover wraps each insert in a SAVEPOINT and, on that specific failure, rolls back just the savepoint and re-queries for what the concurrent job committed -- recovering instead of aborting the whole ingestion job. Added unit tests for the retry mechanism itself; genuinely reproducing the underlying race in an automated test would need real Postgres MVCC timing, which isn't something a deterministic test can force reliably. Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-05 02:27:07 -05:00
NixReaperandClaude Sonnet 5	b4d1e8f755	Add opt-in season cascade to series ingestion ... Ingesting a series only ever produced season stubs -- getting actual episodes meant calling POST /admin/ingest/season once per season by hand, which is exactly what manual end-to-end testing kept requiring for every multi-season show. POST /api/v1/admin/ingest/series now takes include_seasons (default false, since a show can have dozens of seasons and that's dozens of TMDb calls fired from one request). When true, ingest_series_task fans out one ingest_season job per season once the series succeeds, using arq's own ctx['redis'] connection for the job (the same pattern arq's docs recommend for job chaining) rather than a second unrelated connection. Each fanned-out season job still goes through get_or_create_ingestion_job, so re-running a cascaded series ingestion reuses the same season job rows instead of creating duplicates. Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-05 02:03:25 -05:00
NixReaperandClaude Sonnet 5	ec6b5bdd7d	Surface series/episode credits in person filmography ... /people/{id}/credits only ever looked at entity_type == "movie", silently dropping the series-level cast/crew and episode-level guest-star Credit rows that series_ingestion.py has been writing all along -- a person ingested via a TV show would show an empty or movie-only filmography no matter how much TV work was actually in the database. Regular series credits map straight to a filmography row, same shape as movies. Guest-star episode credits are aggregated to one row per (series, department/job/character) with an episode_count, rather than one row per episode -- a prolific guest actor would otherwise flood the list with dozens of near-identical entries. Added tv_repository.get_series_by_ids/get_episodes_by_ids (bulk, mirroring the existing movie_repository pattern) to support it. Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-04 20:00:15 -05:00
NixReaperandClaude Sonnet 5	3f6332559a	Add series/season/episode ingestion pipeline ... Movie and person ingestion existed, but the series/season/episode API endpoints had no way to actually populate them from TMDb -- the biggest remaining gap in Core 0.1's television scope. - normalize_series/normalize_season in the metadata normalizer, including two TMDb quirks that would otherwise silently produce empty data: /tv nests keywords and alternative_titles under "results" (not "keywords"/"titles" like /movie), and series-level creators come from a separate created_by array, not the credits cast/crew lists. - ingest_series upserts the Series row plus season *stubs* (number, title, air date, poster -- everything TMDb inlines on /tv/{id}); ingest_season fetches and upserts one season's full episode list, and requires the series to already exist (TMDb has no single endpoint for a whole series' episodes, so this has to be a separate per-season call). - Wired through the same job-lifecycle path as movie/person ingestion (runner.py, arq tasks, admin endpoints), with the shared boilerplate between them factored into runner._run_ingestion and admin.py:_enqueue rather than copy-pasted a third and fourth time. - Unit tests for both normalizers (runnable without a DB) and integration tests for the full ingest_series -> ingest_season flow, including the series-must-exist-first error and idempotency on re-ingestion. Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-04 19:43:56 -05:00
NixReaperandClaude Sonnet 5	669034896a	Fix job_id mismatch between ingestion enqueue and status endpoints ... POST /api/v1/admin/ingest/movie returned arq's own internal queue job id, but GET /api/v1/admin/ingest/jobs/{job_id} looked up our IngestionJob DB row by its own UUID -- a completely different id that didn't even exist yet at enqueue time (the row was only created once the worker picked up the task). Every status poll 404'd. Fix: create the IngestionJob row synchronously in the enqueue endpoint (reusing the existing idempotency-key logic, so repeat enqueues for the same tmdb_id reuse the same row rather than creating duplicates), pass its real id into the arq task, and have the worker update that row instead of creating a new one. Found by actually running the milestone end-to-end: enqueue a real TMDb ingestion, then poll its status. Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-04 19:28:31 -05:00
NixReaperandClaude Sonnet 5	c20df1c503	Initial Aurora Core 0.1 implementation ... Production-grade media metadata backend per docs/aurora-core-spec.md: Aurora-owned UUIDv7 identity system, normalized movie/TV/people/credits schema, provider abstraction with a TMDb adapter, an idempotent async ingestion pipeline (normalize -> match -> upsert -> provenance), a Postgres FTS/trigram search layer, a stateless FastAPI v1 API with Redis caching/rate-limiting, arq workers, dev/prod Docker Compose topologies, unit + integration + load tests, CI, and architecture/ database/API/ERD documentation. Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-04 17:34:03 -05:00