-
Notifications
You must be signed in to change notification settings - Fork 14
feat(ml): propagate pipeline config through NATS pull-mode tasks #1279
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -86,6 +86,8 @@ def queue_images_to_nats(job: "Job", images: list[SourceImage]): | |
| job.logger.info(f"Queuing {len(images)} images to NATS stream for job '{job.pk}'") | ||
|
|
||
| # Prepare all messages outside of async context to avoid Django ORM issues | ||
| pipeline_config = job.pipeline.get_config(project_id=job.project.pk) if job.pipeline else None | ||
|
|
||
| tasks: list[tuple[int, PipelineProcessingTask]] = [] | ||
| image_ids = [] | ||
| skipped_count = 0 | ||
|
|
@@ -101,6 +103,7 @@ def queue_images_to_nats(job: "Job", images: list[SourceImage]): | |
| id=image_id, | ||
| image_id=image_id, | ||
| image_url=image_url, | ||
| config=pipeline_config, | ||
| ) | ||
|
Comment on lines
89
to
107
|
||
| tasks.append((image.pk, task)) | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -76,6 +76,28 @@ PipelineChoice = typing.Literal[ | |||||||||||||
| "new-pipeline-slug", | ||||||||||||||
| ] | ||||||||||||||
| ``` | ||||||||||||||
| ## NATS Pull-Mode (Async API) Contract | ||||||||||||||
|
|
||||||||||||||
| Processing services that operate in pull-mode (fetching tasks from Antenna via `POST /api/v2/jobs/{id}/tasks/`) receive `PipelineProcessingTask` objects. Each task now includes a `config` field carrying the pipeline configuration for that job: | ||||||||||||||
|
|
||||||||||||||
| ```json | ||||||||||||||
| { | ||||||||||||||
| "id": "42", | ||||||||||||||
| "image_id": "42", | ||||||||||||||
| "image_url": "https://...", | ||||||||||||||
| "reply_subject": "antenna.results.job.7.img.42", | ||||||||||||||
| "config": { | ||||||||||||||
| "example_config_param": 3 | ||||||||||||||
| } | ||||||||||||||
| } | ||||||||||||||
| ``` | ||||||||||||||
|
|
||||||||||||||
| `config` mirrors `PipelineRequest.config` from the synchronous HTTP path. It is derived from the pipeline's `default_config` merged with any per-project `ProjectPipelineConfig` override. It may be `null` if no config is set. | ||||||||||||||
|
|
||||||||||||||
| Workers should read `config` from each task and apply it to their processing. If `config` is absent or null, fall back to worker-level defaults (e.g. environment variables). | ||||||||||||||
|
Comment on lines
+95
to
+97
|
||||||||||||||
| `config` mirrors `PipelineRequest.config` from the synchronous HTTP path. It is derived from the pipeline's `default_config` merged with any per-project `ProjectPipelineConfig` override. It may be `null` if no config is set. | |
| Workers should read `config` from each task and apply it to their processing. If `config` is absent or null, fall back to worker-level defaults (e.g. environment variables). | |
| `config` mirrors `PipelineRequest.config` from the synchronous HTTP path. It is derived from the pipeline's `default_config` merged with any per-project `ProjectPipelineConfig` override. In the normal Antenna code path, it is an object; if no defaults or overrides are set, it may be an empty object. | |
| Workers should read `config` from each task and apply it to their processing. If `config` is unexpectedly absent or `null` (for example, due to a malformed or legacy payload), fall back to worker-level defaults (e.g. environment variables). |
Copilot
AI
Apr 30, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doc implies Antenna will “record [results].config for auditing”, but the backend currently doesn’t appear to persist or otherwise use PipelineResultsResponse.config when saving results (it’s parsed but ignored). Either implement recording on the Antenna side, or soften/reword this guidance so workers don’t expect the value to be stored/visible.
| When returning results, populate `PipelineResultsResponse.config` with the config that was actually used, so Antenna can record it for auditing. | |
| When returning results, you may populate `PipelineResultsResponse.config` with the config that was actually used so your worker reports its effective settings consistently. Do not assume Antenna currently persists, displays, or audits this value when saving results. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
README contract is ahead of in-repo example/minimal implementations.
This says workers should populate PipelineResultsResponse.config, but current in-repo examples still omit it (processing_services/minimal/api/schemas.py:213-244, processing_services/example/api/pipelines.py:117-140). Please add a short note here that those examples need the companion schema update.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@processing_services/README.md` around lines 99 - 100, Update the README to
note that the worker examples must be updated to include the new
PipelineResultsResponse.config field; specifically, mention that the minimal and
example worker schema definitions (module minimal.api.schemas) and the pipelines
example code that builds responses (module example.api.pipelines) need a
companion schema update so they populate PipelineResultsResponse.config with the
actual runtime config used when returning results.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test does not verify default-key preservation in merge.
Line 578 and Line 583 only exercise an overridden key, so Line 619 cannot catch regressions where defaults are dropped instead of merged. Add one default-only key and assert it survives in
task.config.Suggested test tightening
Also applies to: 619-619
🤖 Prompt for AI Agents