Propagate exceptions outside workflow

In my workflow, I have a signal method that takes an external signal and validates the arguments first. The issue is when the signal method is invoked with a bad argument, the validation throws an error, and it is captured by the workflow execution itself, then retried. From the external invocation, the exception is not surfaced and in my case, it is a API call, I would get success for the API call but internally it has a validation failure.
Ideally, either I could synchronously wait for the retry or specify the some exclusion criteria for retries, and surface the exception to the caller right away. How should I achieve that?

You are asking for a synchronous update feature. We have plans to add it, but no ETA.

At this point, the simplest workaround is to use a query to return the workflow state after signaling. Then the query could return the validation results.

Thanks @maxim. Even when I query, is it deterministic that the signal method has completed? Since it runs async, could there be a chance that the query will return an older state?

It is guaranteed that the signal method is called before the query. As a signal method can block for an unlimited amount of time (up to the workflow run timeout) it is not guaranteed that a query will be called only after the signal method returns.

If a signal method doesn’t block then it is guaranteed that the query is called after the signal method returns.

You mentioned

If a signal method doesn’t block then it is guaranteed that the query is called after the signal method returns.

But I got confused after reading your other response for similar issue

The thread seems to indicate that a “polling” mechanism is needed, as opposed to a simple “query after signal” pattern. So does the below code work if I “query after signal” without polling?

// signal
public void change(boolean validation) {
     if (validation) {
         this.isChanged = true
     }
}

// query
public boolean isChanged () {
    return this.isChanged;
}

Yes, it works. The polling is needed when singal initiates some blocking operations like activity executions and their result affects the query result.