d458ed1b34
All sibling services on the box manage schema with Alembic (async env, `alembic upgrade head` in the compose command). matchmaking-v2 was the outlier (Base.metadata.create_all + no migration for the new user_feed.exhausted_at column). Bring it onto the pattern: - alembic.ini + alembic/env.py (async, URL from settings.DATABASE_URL, target = Base.metadata) + script.py.mako — copied/adapted from user-service. - versions/0001_baseline: the current prod schema (user_feed WITHOUT exhausted_at + opportunity_state). - versions/0002_pool_and_exhausted: CREATE user_job_pool + ADD user_feed.exhausted_at (additive). - Dockerfile: COPY alembic.ini + alembic/. requirements: alembic>=1.13.0. Verified both paths: fresh DB → upgrade head builds all 3 tables; prod-like (existing tables+data) → stamp 0001 → upgrade runs ONLY 0002, existing rows survive. 64 tests pass. PROD ADOPTION (one-time): `alembic stamp 0001_baseline` on RDS before the first deploy, then the compose's `alembic upgrade head` applies 0002.
15 lines
348 B
Plaintext
15 lines
348 B
Plaintext
fastapi>=0.115
|
|
uvicorn[standard]>=0.30
|
|
pydantic>=2.7
|
|
pydantic-settings>=2.3
|
|
httpx>=0.27
|
|
redis>=5.0
|
|
# engine/auto-apply deps land in later slices:
|
|
# openai>=1.40 # GPT-5.4 rerank/explain + tailoring
|
|
# apify-client>=1.7 # on-demand board fetch (or call run-sync via httpx)
|
|
openai>=1.40
|
|
numpy
|
|
sqlalchemy[asyncio]>=2.0
|
|
asyncpg
|
|
alembic>=1.13.0
|