Once you get to this point, though, I think it’s worth going back to the solution architecture to see if there is a more idiomatic way to solve the initial problem.
Because: you have to deal with a fundamental impedance mismatch here. If your HTTP request / response times out before the workflow completes (because load or latency, or external dependencies), you may have the web server send some kind of status back to the client, rather than just time out.
But, now you have a workflow in-flight, and no way to communicate the outcome. And, unless you are using start message events with idempotent start messages, or don’t need this operation to be idempotent, if the client retries the request you’ll now have a duplicate workflow instance.
Fundamentally: a workflow is an asynchronous, stateful, potentially long-running process, which can be inspected to get progress updates. And a REST request is asynchronous, but it is a one-shot, and it’s stateful only until the response is sent.
So I think that a callback to the client, either via a webhook (which means you don’t have to manage caching, but your clients do need a web server), or via a server-side results url and client polling, is a better impedance match. This way you can also expose a status endpoint to get progress.
If your workflows are always short-lived, and guaranteed to complete in time for a REST request - response, you still have to deal with the potential failure cases. This includes a partition going under quorum and accepting requests to start workflows, but not actioning them until quorum is achieved. That will definitely mess with a one-shot synchronous HTTP request-response.