In ZAP, why does a `-cmd` run return a failure exit code where a `-daemon` run returns zero?

## Where a process exit code comes from here The control singleton holds a single integer, set through `setExitStatus(status, logMessage)` and read through `getExitStatus()`. Nothing about that field is mode-specific. What *is* mode-specific is whether anybody reads it on the way out, and whether the thing you ran was allowed to set it in the first place. Both halves break on the service path, for different reasons. ## The one-shot path reads it `CommandLineBootstrap.start()` runs the registered work, shuts the program down in a `finally`, and then does the equivalent of "if I have no error of my own, adopt the control singleton's status". `ZAP.main` takes that return value and calls `System.exit` on anything non-zero. So on this path the exit code is a genuine end-of-run verdict, produced after the work has actually finished. The field's own documentation says as much: it notes that setting an exit status works however the program is run, but that it makes more sense in command-line mode. That sentence is the whole leaf in miniature. ## The service path returns before there is anything to report `DaemonBootstrap.start()` builds a thread, starts it, and returns zero. At that instant the plan has not run, the scan has not started, and no verdict exists. The process then stays alive because that thread loops instead of returning. It ends only when something calls `System.exit` explicitly — the control API's shutdown action does, and it passes `getExitStatus()` through, so a daemon *can* deliver a status if you shut it down through the API after something set one. ## And off that path the automation framework will not even record one This is the part that surprises people. The automation add-on has a private helper that every one of its status-setting paths goes through, and that helper begins by asking whether the process type is `cmdline`. If it is not, the helper returns without touching the control singleton and without logging the error line. So under `-daemon`, a plan with errors does not merely fail to *report* a status — it never *records* one. That includes the explicit case. The plan job whose entire purpose is to choose an exit value does not set one directly either: it stores an override on the add-on, and the same gated helper is what would later apply it. The gate is upstream of everything. | what fails | sets an exit status? | gated on | |---|---|---| | an automation plan's errors or warnings | only under the one-shot lifetime | the process type being `cmdline` | | the database or disk filling up | yes, then exits | no view being attached | | a high-level insight with the auto-exit option on | yes, then exits | no view being attached | Notice that the second and third rows are gated on the *absence of a view*, not on the one-shot lifetime. That is the tree-wide asymmetry running the other way: those two are self-termination paths that fire in headless runs and not on the desktop. ## So what does a daemon's exit code mean? It means the process stopped, and usually it means somebody stopped it. It does not mean the scan passed. A pipeline that starts the program with `-daemon`, waits, and then reads the shell's status variable is reading "the service came up", which is true of a run that scanned nothing at all. ## What to do instead - **Run the work under the one-shot lifetime** when the pipeline's decision is "did this pass". That is the only lifetime whose exit code is produced after the work finished and is allowed to carry the automation framework's verdict. - **If you need the service lifetime** — because several steps drive the control API in an order you control — then decide explicitly where the verdict comes from, read it yourself, and shut the process down through its API rather than killing it, so that whatever status was set is actually returned. - **Do not treat a green job as evidence that anything was scanned.** That is true of both lifetimes and doubly true of the service one, where zero is the value you get before the work has even started. - **Diagnose on the service path from the log, not the console.** The reporting helpers that command-line listeners use only write to standard output and standard error when the process type is `cmdline`; everywhere else the same message goes to the log and nowhere visible. ## The trap to name in an interview Say the two halves separately. "The daemon's start returns zero before the work runs" is the obvious half. "And the automation framework's status-setting is gated on the process type, so nothing would have been recorded even if something read it" is the half that shows you have looked.