Ability to control the session id and thus open up to the possibility of retrying failed transactions and deduplication

[danielmarbach]

The proposed solution works well in scenarios when the web request originates from a human action (like clicking a button on a web page). Such actions are not subject to automatic retries. If the request fails, the user is likely to see some error message along with the current state of the data in the database. Based on that state, they are either going to conclude that the action was in fact successful or retry. The act of retrying constitutes another user action.

On the other hand, in the scenarios that involve machine-to-machine communication (one application calling another application's HTTP API) a single machine action is generated, usually with its ID, and retried until success result is returned. In these situations, the HTTP API should provide two guarantees on top of the proposed solution:

• if the incoming HTTP request includes an ID, the controller logic should only be executed once for any incoming ID
• the response the controller returns should the identical for each retry that carries the same request ID

The control message could also be hold as an indication that SessionId has been provided by the user. In such a case, the control message would never be acknowledged, causing it potentially end-up in the error queue. This, in turn, could be used to handle HTTP-based integration scenarios when there is a stable/well-defined request id.

To support such a scenario it would require the possibility to override the SessionId to a stable id defined by the user or the middleware and a control message header that makes sure the incoming control message behavior is bypassed to not tombstone the control message after the timeout has elapsed but instead move it into the error queue.