The specification as is is a bit unclear around the behavior/expectation that a client might have from a server when a client is specifying a wait preference in case there is not also a respond-async preference.

8.2.8.10 describing this behavior in our specification, whilst referencing RFC7240, states that if the respond-async preference has not been specified, the service MAY interpret the wait as a request to timeout after the specified period of time.

The referenced Prefer Header for HTTP specification in section 4.3 pertaining to the "wait" preference states however that a service can choose to utilize an asynchronous processing model in that case and return a 202 Accepted.

Looking at 9.1.3 in the OData protocol specification pertaining to the 202 Accepted Response Code, whilst stating that is returned when an asynchronous request hasn't been completed yet, refers to the sections on asynchronous requests.

Whilst one doesn't preclude the other it has caused confusion in our interpretation/implementations so I thought some clarification might be in order.

Proposal

Be specific about the behavior of the status monitor resource regarding wait:

If a client queries the status monitor resource with a wait preference, the preference applies to the status query and not to the original request that is/was processed asynchronously. A server may

• ignore this preference on a status query, or
• send 202 Accepted if it cannot figure out within the given length of time whether the original async request is still being processed (i.e. assume it is still running)

Imported from ODATA-1610