Commit Graph
2 Commits
Author SHA1 Message Date
NixReaperandClaude Sonnet 5 1cdfbc59ac Fix test isolation: trending tests were leaking data into other tests
CI / lint (push) Canceled after 0s
CI / typecheck (push) Canceled after 0s
CI / unit-tests (push) Canceled after 0s
CI / integration-tests (push) Canceled after 0s
CI / container-build (push) Canceled after 0s
CI / dependency-audit (push) Canceled after 0s
Not a bug in production code -- refresh_trending()'s tests use
session_scope() for real, permanent commits (necessary, since
refresh_trending manages its own sessions), unlike every other
integration test's db_session fixture, which rolls back after each test.

FakeTrendingProvider reused FAKE_MOVIE/FAKE_SERIES unmodified except for
id/title, so every synthetic trending movie/series carried the same
embedded video id and imdb_id -- values meant to be globally unique per
real TMDb entity. Those commits were never rolled back, so they
permanently occupied uq_video_provider_source/uq_external_id_source in
the shared test database for the rest of the run, causing
test_watch_providers.py (which runs later alphabetically and ingests the
same fixtures unmodified via the normal rolled-back db_session) to
collide against leaked data with 14 failures that had nothing to do with
watch providers.

Found by actually running the full suite against real Postgres --
confirms it was worth doing before this deploys.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
2026-09-06 07:45:39 -05:00
NixReaperandClaude Sonnet 5 4403305da6 Add trending movies/series, refreshed on a schedule
CI / lint (push) Canceled after 0s
CI / typecheck (push) Canceled after 0s
CI / unit-tests (push) Canceled after 0s
CI / integration-tests (push) Canceled after 0s
CI / container-build (push) Canceled after 0s
CI / dependency-audit (push) Canceled after 0s
Mirrors TMDb's own /trending/{movie|tv}/{day|week} ranking rather than
Aurora computing trending itself from popularity deltas -- that would
require re-syncing the entire catalog on a schedule, infeasible at any
real scale, whereas TMDb already computes this well from signals (real
view/search velocity) Aurora has no access to.

New: TrendingEntry model + migration 0003, MetadataProvider.get_trending
(concrete/optional, like aclose(), so existing test fakes don't all need
updating), refresh_trending() which actually ingests each trending item
(only ~20 per window, cheap enough to fully ingest rather than apply the
never-fabricate-a-stub rule recommendations uses), a twice-daily arq cron
job (WorkerSettings.cron_jobs, new to this codebase), a manual admin
trigger for right after a deploy, and GET /movies/trending + GET
/series/trending.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
2026-09-06 05:18:02 -05:00