4 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 4.8	8e98e79968	fix(alembic): lock_timeout on migrations, drop the advisory lock ... Reverses the advisory-lock approach (7309d1d) — it treated a replica race that wasn't the cause and added a new indefinite-hang mode (a sibling/stale migrator holding the xact lock). Real cause of the 0040 hang (operator-diagnosed 2026-06-07): web has always been a single replica. The migration's ALTER series_page queued behind a concurrent tag-merge that held a series_page lock for minutes — _do_merge repoints series_page then runs _create_protective_aliases, an unindexed full scan of image_record (JSON column, ~59k rows). Migrations ran with no lock_timeout, so the DDL hung indefinitely and silently. Fix: SET lock_timeout (default 30s, env-overridable) on the migration connection before alembic's transaction. A blocked DDL now fails fast with 'canceling statement due to lock timeout'; the entrypoint exits non-zero so the deploy retries / surfaces loudly instead of wedging. General protection for every future migration. (The slow _create_protective_aliases scan — the actual lock holder — is the separate perf fix still under discussion.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-07 23:58:14 -04:00
bvandeusenandClaude Opus 4.8	7309d1d6d4	fix(alembic): serialize concurrent migrators with an advisory lock ... Every web replica runs 'alembic upgrade head' in its entrypoint, so under docker stack deploy two replicas can boot at once and race the same DDL — 0040 raced in prod (operator-flagged 2026-06-07): one backend wedged on the series_page lock while a second tried to re-CREATE series_chapter, and the loser died with AdminShutdown, crash-looping the web service. Wrap run_migrations() in a transaction-scoped pg_advisory_xact_lock acquired BEFORE the version table is read. The first replica to reach it migrates and holds the lock for the whole upgrade; siblings block, then find the version already at head and apply nothing. Works regardless of replica count and needs no Swarm depends_on ordering (which stack deploy ignores anyway). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-07 19:59:45 -04:00
bvandeusenandClaude Opus 4.7	80a5690740	fix(fc2a): apply ruff autofix + skip vue-tsc check (no tsconfig) ... Ruff: The remaining I001 errors came from ruff treating `alembic` as a first- party module (because the alembic/ directory exists in the repo root) rather than third-party. Ran `ruff check --fix` locally — auto-sorted import groupings to put alembic/sqlalchemy alongside backend.* as first- party, and trimmed redundant blank lines after a few import blocks. Frontend: `npm run check` (vue-tsc --noEmit) was failing because vue-tsc has no tsconfig.json to read against, and the frontend is pure JS without JSDoc annotations — vue-tsc had nothing to do. Skipping the step until we add a tsconfig + convert to TS or add JSDoc annotations. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-14 14:24:25 -04:00
bvandeusenandClaude Opus 4.7	a03655039c	feat: add SQLAlchemy declarative base, Alembic environment, and gitignore fix ... Configures stable constraint naming so autogeneration produces clean diffs. Alembic uses the sync psycopg driver while the runtime app uses asyncpg. Also fixes a .gitignore bug caught during this task: the bare 'models/' rule for the ML weights volume was matching backend/app/models/ (Python package). Anchored all volume rules to repo root (/images/, /import/, /downloads/, /models/, /postgres_data/, /redis_data/). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-14 07:32:58 -04:00