A ZAP automation plan names a job type the installed build does not ship. What happens to the run?
answer
- add-ons register job types
- the name resolves to nothing
- an error, not a skip
- checked before the first job
- Unrecognised job type
basics
~20 sA ZAP plan naming a job type no installed add-on registers fails while it loads, with Unrecognised job type recorded as an error. The run then stops before any job executes: the environment is created and nothing else.
solid answer
~40 sJob types are not built into the framework: each one is registered by whichever add-on owns it, into a map keyed by the type string. The `automation` add-on registers only a handful itself; everything else arrives with another add-on. If the build has no add-on claiming the type in your plan, the loader records `Unrecognised job type: <type>` as an **error**, and because the run checks for accumulated errors after creating the environment and before the first job, **no job runs at all** — not just the missing one. The message cannot distinguish a typo from an absent add-on, and the plan cannot repair itself: the `addOns` job that once installed add-ons is deprecated and now only logs a warning.
go deeper
Remember that job types come from add-ons, not from the framework, and that a plan naming one the build lacks fails to run. Know that -autocheck will tell you before a scan does.
Explain the lookup: the type string is resolved against a registry the add-ons fill, an unresolved name is recorded as an error, and the error is checked before the first job rather than at that job's turn.
Demonstrate the operational reading: pin the add-on set alongside the plan, gate plans with -autocheck, and treat 'the run finished' as insufficient evidence that any job executed.
Own the supply question this exposes — a plan is portable only as far as the build it lands on, so someone has to decide who owns the scanning image and how a change to its add-on set is reviewed.
## Where job types come from A plan's job entry names a `type`, and the framework resolves that string against a registry. The registry is filled at start-up, by each add-on registering the jobs it owns: - the **`automation` add-on itself** registers only a small set: `activeScan`, `activeScan-config`, `activeScan-policy`, `requestor`, `delay`, `exitStatus` and the deprecated `addOns`; - the crawling jobs arrive with the crawling add-ons; - the reporting and summary jobs arrive with the reports add-on; - the jobs that import an API definition arrive with the add-on that understands that format; - and the shipped help says so outright — the framework is pluggable, and other add-ons may add support for other jobs. So the set of job types a plan may use **is a property of the build it runs on**, not of the framework itself. A plan is portable only as far as the add-on set under it. ## What happens when the lookup fails 1. The plan is parsed. For each job entry, the `type` is looked up. 2. No registered job answers to that name, so the loader records **`Unrecognised job type: <type>`** — an **error**, not a warning — and moves on to the next entry. The unknown job is simply absent from the assembled job list. 3. The run begins: the environment is created, contexts and users come into being. 4. Before the first job, the run checks whether anything has been recorded as an error. Something has, so it finishes there and returns. 5. The command-line exit value is derived from the outcome: an error means the error value. The consequence is the part that surprises people: **one unknown job type does not cost you that job, it costs you the whole plan.** The jobs written above it in the file do not run either, because the check happens before the loop, not inside it. ## The check is not the flag you think it is `env.parameters.failOnError` does not rescue this. That switch governs whether the plan abandons the jobs it has **not yet run** after a job has recorded an error. The gate before the first job tests the recorded errors directly, so a load-time error stops the plan whatever `failOnError` and `continueOnFailure` say. ## The message tells you less than it seems `Unrecognised job type` is the same message for two different faults: | what actually happened | what the message says | |---|---| | the type is misspelled | `Unrecognised job type` | | the type is spelled correctly, the owning add-on is not installed | `Unrecognised job type` | Nothing in the output names an add-on, because at that moment nothing in the program knows which add-on would have claimed the string. A missing add-on and a typo are indistinguishable from the console. ## How to find out what this build has - **Generate a template.** `-autogenmax` and `-autogenmin` write a starting plan composed from the job types the running build has registered, deprecated ones filtered out. The template is therefore build-specific, and a type that appears in it is certainly runnable here. It is not a complete census, though: the generator leaves out deprecated job types and the ones the framework classifies as data jobs, so absence from the template is a strong hint rather than a proof. - **Check before you run.** `-autocheck <source>` loads and validates a plan and reports exactly the same error, without creating an environment or running anything, so an unrunnable plan can be caught by a cheap pipeline step rather than by a long scan that never starts. ## You cannot fix it from inside the plan The obvious repair — have the plan install what it needs — is not available. The **`addOns` job is deprecated**: verifying it, applying it and running it each do nothing but log the same deprecation message, and both of its shipped templates are empty files. The job type still exists, so a plan containing it still loads; it simply has no effect. That is the sharpest form of the rule this whole subject keeps teaching: **the existence of a name is not evidence of a capability.** And because that message is a warning rather than an error, an `addOns` job left in an otherwise clean plan is enough to move the run off a clean exit value — even when the job is marked `enabled: false`, since the deprecation is logged while the plan is being verified, not while it is being run. ## What a pipeline should do about it Pin the add-on set your plans depend on as part of the image or runtime you scan with, and treat a change to it as a change to the plan. Run `-autocheck` on every plan in the repository as a fast gate. And read the run's own output rather than only its exit value: "no jobs ran" and "every job ran and found nothing" both look like a finished run from the outside, and only one of them is a scan.
- Can a plan install the add-on it needs?No. The `addOns` job is deprecated: verifying, applying and running it each only log a deprecation message, and its shipped templates are empty. The job type still exists and still loads, which is exactly why it misleads — existence is not capability.
- Does `failOnError: false` let the rest of the plan run anyway?No. That switch decides whether the plan abandons jobs it has not yet reached once a job has failed. The gate before the first job inspects the recorded errors directly, so a load-time error such as an unknown job type stops the plan regardless of that setting.
- How would you tell a typo from a missing add-on?Generate a template with `-autogenmax` on the same build: it is composed from the job types actually registered there, so most of what that build can run appears in it. If your spelling appears in it, the build has that job and the plan has some other fault. Absence is weaker evidence, because deprecated and data jobs are left out of the generated file.
It behaves like a build file naming a plugin that is not on the classpath. The file is perfectly valid text; the name simply resolves to nothing, and the build refuses before it starts rather than skipping that one step.
saying these in an interview costs you the question
- Says the unknown job is skipped and the rest still runs
- Thinks failOnError: false gets the plan past it
- Reads the message as proof of a typo
- Believes the addOns job can install the missing add-on
- Assumes every job type ships with the automation add-on