Run Workflow

Sanitized failure reason for a FAILED job; None otherwise.

Documents that failed so far. Read it against processing_status, which says whether the job has reached a verdict: on a job that has not finished, 0 means none recorded yet, not that every input produced output.

Why a COMPLETED job delivered no document.

Read for what a run did; the verdict only says whether anything was lost. A run whose source handed back nothing finishes processing_status: SUCCESS with an empty destination, and without this there is no statement anywhere that it moved nothing (Pylon 2287, PLU-622). A run that discovered documents and delivered none of them without failing any is FAILED, and carries this for the same reason: nothing else on the row explains it. A run whose documents failed carries none of these; /failed-files explains it.

So the verdict cannot be used to find these runs, and a caller that wants to know whether a job delivered anything branches on this field.

Its own type on its own nullable field, deliberately NOT a JobProcessingStatus member: that enum is on the public wire and a closed generated-SDK enum breaks a whole list_jobs page on one unrecognised value (DTPL-696, REJECTED).

Null is "no issue detected", never "checked and fine" -- a caller must not read the absence of a value as a guarantee, and a job FAILED for some other reason (a failed document, a preflight rejection) carries none of these. New members may be added; treat an unrecognised one as "an issue was detected, of a kind this client does not know".