(warning: AI generated issue, make sure to vet before implementing)
Problem
The E2E workflow (.github/workflows/e2e.yaml) never exercises the worker at runtime. It builds the worker image but starts only web + its deps, because the worker executes jobs that hit paid LLM/scraper APIs and we skip it to avoid those costs.
This was made explicit in #368, but the gap predates it: even when the workflow previously did docker compose up -d --build (worker included) followed by stop worker, that gave no worker runtime safety — up -d returns as soon as containers start without waiting for health, the worker has no healthcheck and nothing depends_on it, and stop on an already-crashed container is a no-op. So a worker that boots and immediately crashes (bad migration, missing env var, broken import, queue-connection failure) would never fail CI.
Current coverage after #368:
- ✅ Worker image builds (
docker compose build fails CI on a broken Dockerfile)
- ❌ Worker boots / connects to its queue + DB
- ❌ Worker picks up and processes a job end-to-end
Goal
Catch worker runtime regressions in E2E without incurring paid-API execution costs.
Possible approaches (for discussion)
- Smoke-only (cheap, high value): start the worker, assert it reaches a healthy/ready state (boots, connects to Postgres + queue, no crash within N seconds). Requires giving the worker a healthcheck or a readiness signal so we can wait on it deterministically rather than
sleep. Catches the most common failure mode (worker won't start) with zero API spend.
- Job round-trip with a stub provider: enqueue a job via seed/API and assert the worker claims it, transitions its status, and writes results — but route LLM/scraper calls to a mock/fake provider (or a
dry-run/echo mode) so nothing real is billed. Verifies the full queue → worker → DB path.
- Gated real run: keep the default CI path cost-free; allow an opt-in
workflow_dispatch input (or a label) that runs one real job against live providers for periodic deeper validation.
(1) is the obvious first step and is independently useful. (2) is the higher-fidelity follow-up and mainly needs a no-cost provider path the worker can be pointed at in CI.
Context
(warning: AI generated issue, make sure to vet before implementing)
Problem
The E2E workflow (
.github/workflows/e2e.yaml) never exercises the worker at runtime. It builds the worker image but starts onlyweb+ its deps, because the worker executes jobs that hit paid LLM/scraper APIs and we skip it to avoid those costs.This was made explicit in #368, but the gap predates it: even when the workflow previously did
docker compose up -d --build(worker included) followed bystop worker, that gave no worker runtime safety —up -dreturns as soon as containers start without waiting for health, the worker has no healthcheck and nothingdepends_onit, andstopon an already-crashed container is a no-op. So a worker that boots and immediately crashes (bad migration, missing env var, broken import, queue-connection failure) would never fail CI.Current coverage after #368:
docker compose buildfails CI on a broken Dockerfile)Goal
Catch worker runtime regressions in E2E without incurring paid-API execution costs.
Possible approaches (for discussion)
sleep. Catches the most common failure mode (worker won't start) with zero API spend.dry-run/echomode) so nothing real is billed. Verifies the full queue → worker → DB path.workflow_dispatchinput (or a label) that runs one real job against live providers for periodic deeper validation.(1) is the obvious first step and is independently useful. (2) is the higher-fidelity follow-up and mainly needs a no-cost provider path the worker can be pointed at in CI.
Context
.github/workflows/e2e.yamldocker/Dockerfile(workerstage) →npx tsx src/index.ts