Why webjobs api always returns "Accepted" status not 200 Ok

Question

I am trying to run my azure web jobs through c# code but it works but it's return accepted status with 202 status code.

I am using below code for the same code snippet for webjob api call from web app.

Answer 1

It sounds like you may doubt that the HTTP response status code should be 200 OK, not 202 Accepted if a HTTP requst have been handled successfully. However, either 200 OK or 202 Accepted is legal and reasonable, please refer to the 10 section 10 Status Code Definitions of W3C RFC-2616 to know them in depth, as below.

10.2.1 200 OK The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:

GET an entity corresponding to the requested resource is sent in the response;

HEAD the entity-header fields corresponding to the requested resource are sent in the response without any message-body;

POST an entity describing or containing the result of the action;

TRACE an entity containing the request message as received by the end server.

10.2.3 202 Accepted The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this.

The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.

Meanwhile, two code comments below from GitHub Kudu repo explain why used 202 Accepted for triggering webjobs in here.

I. Kudu.Services/ServiceHookHandlers/FetchHandler.cs#L111

// Return a http 202: the request has been accepted for processing, but the processing has not been completed.

II. Kudu.Services/Jobs/JobsController.cs#L191

// Return a 200 in the ARM case, otherwise a 202 can cause it to poll on /run, which we don't support
// For non-ARM, stay with the 202 to reduce potential impact of change

It's up to the design intent of services.