MyJobs workerCmd override is silently ignored — WorkerCmd missing from orchestrator schema

Start by running get-service-schema for eyevinn-python-job-runner, then inspect scripts/docker-entrypoint.sh, the Dockerfile, README, and deploy-manager/src/myjobs/trigger.ts:122-124. Confirm where the orchestrator schema is registered or generated before changing it. Done means WorkerCmd appears in the schema, reaches the container as WORKER_CMD, runs the specified script, and the root cause is documented in docs/repo-patterns-ai-infra.md or the identified documentation location.

Summary

Providing a custom entrypoint override (workerCmd on create-my-job / update-my-job) for a MyJobs scheduled job does not work. The value is sent by deploy-manager but never reaches the container as WORKER_CMD, so the job silently falls back to the repo's default entry point (job.py/main.py) instead of running the script the tenant specified — with no error surfaced anywhere.

Evidence

Live schema check right now (get-service-schema for eyevinn-python-job-runner):

name (required), SourceUrl (required), GitHubToken, OscAccessToken, ConfigService, ConfigApiKey

WorkerCmd is not in this list. Also missing: SubPath, GitToken, OscEnv — all documented as supported by the runner (see below) but absent from the registered schema.

deploy-manager (~/Code/eyevinn/osaas-deploy-manager/src/myjobs/trigger.ts:122-124) does send it correctly:

if (job.workerCmd) {
  jobBody['WorkerCmd'] = job.workerCmd;
}

forwarded via createJob(ctx, 'eyevinn-python-job-runner', token, jobBody).

The runner itself honors it correctly if it arrives — scripts/docker-entrypoint.sh in this repo:

if [ -n "${WORKER_CMD:-}" ]; then exec sh -c "$WORKER_CMD"; ...

and the README documents WORKER_CMD as the override env var. So the container-side logic is fine — the value just never gets there, because the orchestrator schema doesn't declare the field, so unrecognized fields in the job-creation request are silently dropped rather than mapped to an env var.

Real-world impact: tenant birme's job myloppisloppiskartanfix was created with workerCmd: "python3 jobs/import_loppiskartan.py". Given this gap, that value was almost certainly never passed through — the container would have run whatever default entry point (job.py/main.py) the entrypoint script falls back to instead (or failed with "no entry point found" if neither exists in the repo), with no indication to the tenant that their override was ignored.

Relationship to #1 (closed)

This is the same symptom class as #1 (schema missing fields the runner supports), but a different, still-unresolved instance of it. #1 was closed because its specific claim (ConfigSvc vs ConfigService) turned out to be a field-naming mismatch in deploy-manager, not a missing-from-schema problem — and that field-name bug has since been fixed (ConfigService is correctly present in the live schema today). WorkerCmd is a different case: it is not a naming mismatch, it is entirely absent from the schema regardless of casing, and deploy-manager already sends the correct PascalCase name for it.

I checked this repo's Dockerfile (both here and in the eyevinn-osaas/python-job-runner prod fork) and confirmed it has zero ENV declarations — so if the schema really is derived from Dockerfile ENV statements (as #1's original theory assumed), that would explain the gap for every undeclared field, not just WorkerCmd. But birme's closing comment on #1 states the opposite — that "the schema fields ARE correctly defined in the catalog service" independent of the Dockerfile. Given ConfigService/SourceUrl/OscAccessToken/GitHubToken/ConfigApiKey genuinely do work today while WorkerCmd/SubPath/GitToken/OscEnv genuinely don't, whoever picks this up should first confirm where the schema for this service is actually registered/generated (Dockerfile ENV + osaas-service-builder, vs. a catalog-manager entry, vs. something else) before proposing a fix — that ambiguity is exactly what caused #1 to be misdiagnosed.

Suggested fix

1. Identify the actual source of truth for this service's orchestrator schema (see note above).
2. Add WorkerCmd (and ideally SubPath, GitToken, OscEnv while touching this, since they have the identical gap) to that source.
3. Remake the eyevinn-osaas/python-job-runner service so the orchestrator schema regenerates.
4. Verify: a create-my-job with workerCmd set actually results in WORKER_CMD being present in the container env, and the specified script — not the default entry point — is what runs.

Acceptance criteria

• get-service-schema for eyevinn-python-job-runner includes WorkerCmd
• A MyJob created with workerCmd set has WORKER_CMD present in the triggered container's environment
• The tenant's specified script runs instead of the default job.py/main.py fallback
• Root-cause note added to docs/repo-patterns-ai-infra.md (or wherever this service's schema-registration mechanism ends up being documented) so the next missing-field report doesn't get misdiagnosed a third time

🤖 Generated with Claude Code

Co-Authored-By: Claude noreply@anthropic.com