[mihow]

Summary

Pull (async) mode is now the default way processing services work with Antenna, but the template service in this repository only worked in push mode, and nothing in CI exercised pull mode end to end. This PR makes the minimal template work as a pull-mode worker against the current jobs API and vector contract, and adds a CI job that runs a real async job through it and checks that the results, including feature vectors, are stored. It builds on the draft worker in #1252, which is merged in rather than rewritten, and on the parity work in the base PR.

List of Changes

Change (effect)	How	Notes
The template can run as a pull-mode worker (MODE=worker or api+worker) that registers its pipelines and processes async jobs	From #1252: start.sh, register.py, worker/ and ensure_default_project, which creates the default project, user and a small image collection at startup when ENSURE_DEFAULT_PROJECT=1	Merged from the draft, credit to its author
The worker finds its jobs the same way the AMI Data Companion worker does	One GET /jobs/ call with pipeline__slug__in, ids_only, incomplete_only and dispatch_mode=async_api, using the pipeline slug each job carries	Antenna records this call as the worker's heartbeat, and synchronous jobs are no longer listed only to fail at /tasks/
Async results carry feature vectors	The worker runs the same pipelines as push mode; its config comes from AMI_INCLUDE_LOGITS, AMI_FEATURES_FOR_ALL_DETECTIONS and AMI_EMBEDDING_EXTRACTOR, because pull-mode tasks carry no config yet (#1422)
Feature-only pipelines are not offered in pull mode	Tasks carry an image and never detections, as in the AMI Data Companion
Misconfiguration fails at startup, not on every task	The worker stops when AMI_PIPELINES leaves no pull-mode pipeline, or when AMI_EMBEDDING_EXTRACTOR names an extractor no pipeline offers
CI runs an async job end to end	New workflow job test-async-processing-service runs scripts/ci/async_processing_service_e2e.sh against a worker service (ml_backend_worker, behind the async compose profile); test_ml_job_e2e gains --timeout and exits non-zero when the job does not succeed	The existing test job is unchanged
The worker's tests run in CI	worker/test_worker.py against a fake Antenna client

Testing

• Minimal service and worker unit tests: 24 pass.
• The async e2e script on a fresh local CI stack: job SUCCESS, 6 vectors of length 8 stored for 6 detections.
• Full backend suite: 938 tests pass (2 skipped); makemigrations --check reports no changes.

Notes for review

• Scope: about 1,050 of the lines are Add processing service v2 template to main docker compose stack #1252's bootstrap and start-mode work; the worker update itself is about 220 lines. If Add processing service v2 template to main docker compose stack #1252 merges first, this diff shrinks to the update. The bootstrap overlaps feat: API key auth and identity for processing services #1194 (register.py, start.sh).
• Until pull-mode tasks carry the project's pipeline config (Send the pipeline configuration to processing services in both push and pull mode, per project and per job #1422, feat(ml): propagate pipeline config through NATS pull-mode tasks #1279, ADC Setup and use React Query #146), the same project can get different vectors in push and pull mode.
• Not covered here: client_info is accepted by the jobs API but not yet used, and the lost-acknowledgement redelivery path is not exercised.

Stacked on #1511. Related: #1252, #1046, #1422, #1279, #1194.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TNNRg9NDr6opFZgK3nxx5C

[netlify]

✅ Deploy Preview for antenna-preview ready!

Name	Link
🔨 Latest commit	120d023
🔍 Latest deploy log	https://app.netlify.com/projects/antenna-preview/deploys/6acea07b17aebf6c60f2f877
😎 Deploy Preview	https://deploy-preview-1512--antenna-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 57 (🔴 down 8 from production) Accessibility: 82 (🔴 down 7 from production) Best Practices: 92 (🔴 down 8 from production) SEO: 92 (no change from production) PWA: 80 (no change from production) View the detailed breakdown and full score reports
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[mihow]

Claude says: A related gap, found while fixing project creation in #1413: a pull-mode worker registers its pipelines only for the projects that exist when it registers. A project created later gets none of them until registration runs again. In this template, start.sh runs register.py once at container start, for the single project named by ANTENNA_PROJECT_ID or ANTENNA_DEFAULT_PROJECT_NAME. That suits a local stack, but it is the same one-off pattern.

The data companion side is tracked in RolnickLab/ami-data-companion#179. If the template keeps its own registration, it may be worth matching whatever is decided there, for example re-registering on a schedule. #1194 (API-key auth for processing services) overlaps the same registration code.