Adding resiliency around using asynchronous request

[Hubert-Heijkers]

When executing request asynchronously the client depends on receiving the [202] response from the service containing the location header to the status monitor URL. And once this status monitor URL is interrogated using a GET request against it the standard allows for a different status monitor URL to be returned to continue the loop, creating another possibility for the client not to receive the response and loosing access to the final results of the asynchronously executed, potentially/typically long running, request.

The client would therefore have a deterministic way to determine the location of the status monitor resource which likely implies that the client would also need to be able to provide a unique ID, a UUID (or GUID) presumably, to identify the asynchronous operation.

[Hubert-Heijkers]

A thought that has been discussed is to link the asynchronous job to the request that initiated it and allow the requester to specify the X-Request-ID header, which would then become the ID of the asynchronous operation, and in the case of TM1 the ID used in the ./_async(<<x-request-id>>) resource monitor URL.

As a result of this the resource monitor URL of a given asynchronous operation would have to become a stable ID and even if the a client did not specify a request ID we would propose that it would become stable after that as that way one could store these and re-interrogate them later.

[ralfhandl]

Could Repeatable Requests help achieving resiliency instead of a constructable monitor resource URL?

[Hubert-Heijkers]

The issue is that the requests that are being executed asynchronously are by themselves not repeatable but we'd want to have a, similar perhaps, pattern to figure out if by any chance the request is, or has been executing asynchronously to not have to do it again.

But I'm guessing what you are saying is if you execute a repeatable request, irrespective of it being executed asynchronously or not, a service could perhaps figure out using the Repeatable Requests pattern the request has, or potentially is still, been executed and if the respond-async preference is being repeated it could even respond similarly on the repeat of the request.

[ralfhandl]

Annotate $metadata with something like

@TM1.monitorResourceUrlTemplate: "./_async({x-request-id})"