When a job is pending execution with status: created, and that POST /jobs/{jobId}/results is requested to trigger its execution, an implementation can still choose this "trigger" to simply consist of placing the job in queue for processing (as if it was directly submitted originally by Prefer: respond-async).
Therefore, even if the execution trigger was acknowledged, it might still not have been performed "yet", due to pending resources acquisition or other prerequisites. For this reason, a server might prefer to highlight this situation using HTTP 202 Accepted rather than "HTTP 200 OK". The HTTP 200 OK can give the wrong impression that resources (i.e.: GET /jobs/{jobId}/results) would now be available, when in fact they are almost certainly not yet ready for a long processing graph/workflow.
Referring to this requirement:
https://github.com/opengeospatial/ogcapi-processes/blob/02627da57ab4782fdf41d8e8f421dd3c9b422eb6/extensions/job_management/standard/requirements/job-management/start/REQ_response.adoc?plain=1#L6C1-L6C110
When a job is pending execution with
status: created, and thatPOST /jobs/{jobId}/resultsis requested to trigger its execution, an implementation can still choose this "trigger" to simply consist of placing the job in queue for processing (as if it was directly submitted originally byPrefer: respond-async).Therefore, even if the execution trigger was acknowledged, it might still not have been performed "yet", due to pending resources acquisition or other prerequisites. For this reason, a server might prefer to highlight this situation using HTTP 202 Accepted rather than "HTTP 200 OK". The HTTP 200 OK can give the wrong impression that resources (i.e.:
GET /jobs/{jobId}/results) would now be available, when in fact they are almost certainly not yet ready for a long processing graph/workflow.See https://github.com/opengeospatial/ogcapi-processes/issues/451#issuecomment-2426624016 for details about the execution modes.