I have a flow where the client initiate a new workflow but it doesn’t wait for the result in-line. Instead it will do some other stuff and come back later. For example:
WorkflowClient workflowClient = ...;
WorkflowOptions options = ...;
var workflowInstance =
workflowClient.newWorkflowStub(MyWorkflow.class, options);
WorkflowExecution workflowExecution = WorkflowClient.start(workflowInstance::execute, request);
When that moment arrives, it will need to check workflow status and based on that, get the result or continue doing some other stuff (the idea is not to park the thread). I am using versión 1.14.0 of temporal.io/sdk-java and I came across this snippet code I am using:
WorkflowClient workflowClient = ...;
WorkflowExecution workflowExecution = ...;
var stub = workflowClient.newUntypedWorkflowStub(execution.getId(), Optional.of(execution.getRunId()), Optional.empty());
Result result = stub.getResult(1L, TimeUnit.SECONDS, Result.class);
The thing is that I see some DEADLINE_EXCEEDED and UNAVAILABLE errors when that 1 second is reached since the workflow execution is still in progress.
Looking at this response. I can:
- Use a query feature to retried a custom workflow internal state. I will then, based on this state, call the
getResult
. - Continue as I am doing, and discarding the DEADLINE_EXCEEDED and UNAVAILABLE errores, considering them it just part of the business logic.
- Use DescribeWorkflowExecution API in replace of the custom Query of point 1, and based on workflow Status call the
getResult
.
I find option 1 a little bit of unnecessary since I can use DescribeWorkflowExecution API to achieve the same without adding a new value to store to Temporal.
Option 2 seems risky, I might end up considering unwanted errors to be treated as expected and metrics become dirty.
Option 3 seems the best approach, I will probably have 5 to 10 attempts of describe an in-progress workflow execution before it actually ends and I can get the result. And since this is a heavy used API I might end-up with more than 1000 request per minute at peak.
What is the overhead of these solutions?
Thanks!