[Interceptor determinism] Workflow Replay with Interceptors is executing same interceptor code again

Community Support
,
1

I wrote an Interceptor and doing some DB operation in WorkFlow Interceptor .

Every time I open the Ui and open the same workflow history the interceptor is also executing and the same DB operation is happening again and again .

Is it expected to have the same level of Determinism inside Interceptor as workflow ?
How can we detect replay events inside interceptors and avoid such issues?

2

I was able to solve this by using Workflow.sideEffect . I can see the side effect value as a MarkerRecord in UI event history.Want to check if this is ok to use them inside Interceptor .

4

Hi,

Can I ask why you need to do DB operations inside an interceptor? I think that the right place to do DB operations is activities.

5

We will have several work flows and they have some pre and post work to be done .
I understand that having DB interaction inside workflow /workflow interceptor makes the workflow non deterministic.

If we have to enforce some common pre and post processing work (Non deterministic) across many workflows how can we achieve them ?

7

Hi @mrt

if you are calling your db through an activity method it should not be called again on workflow replay, even if you do it from an interceptor. Are you using activities to perform your DB operations?

checkout this code from @tihomir , it might be useful for you

8

The different work flows may have different logic to call DB through their own Activities.
However we have few requirements to do before /after each work flow call .

I looked at the sample code you shared and thats exactly what I was looking for . This should work .Will test and let you know.

Thanks a lot

9

Thank @antonio.perez I tested this and it works .I have couple of further questions on Versioning.

Now Imagine either we add more Workflow interceptors or make changes to an existing Workflow interceptor .Will the workflow versioning work for these use cases.

Since the workflow versioning is specific to workflow and these are common interceptors across many work flows will this cause any issue ?

2nd Question: If I have many activities I have to keep supplying Activity Options to all Activities .I am aware of WorkflowImplementationOptions .Will it help to have an Api at WorkflowOptions.setActivityOptions or workflowClient.newWorkflowStub(activityOptions) .
This way we can have the same activity options for every activity and they can be overridden at every Activity label also. Any opinion on this?

Thanks

10

Since the workflow versioning is specific to workflow and these are common interceptors across many work flows will this cause any issue ?

Workflow versioning is specific to the part of code that is versioned. It is not global to the workflow. So it works for shared libraries, as in your case without a problem. The tricky part would be the deprecation of old versions as a library developer doesn’t usually have real control over code upgrades.

2nd Question: If I have many activities I have to keep supplying Activity Options to all Activities .I am aware of WorkflowImplementationOptions .Will it help to have an Api at WorkflowOptions.setActivityOptions or workflowClient.newWorkflowStub(activityOptions) .
This way we can have the same activity options for every activity and they can be overridden at every Activity label also. Any opinion on this?

The activity options are an implementation detail of a workflow. That’s why they are set on WorkflowImplementationOptions. The workflow starter usually doesn’t care about workflow implementation. Se setting them there doesn’t make sense for the general use case. If you really want that you can pass the options as a workflow argument. Or you can use context propagators if you want to pass them implicitly.