Continuous child workflow

This works as designed :). This is a commonly used pattern for a parent to watch the child which calls continue as new periodically.

The tricky part is updating workflow code when you have open workflows.
Use WorkflowContext.isImplementationVersion (https://github.com/aws/aws-swf-flow-library/blob/master/src/main/java/com/amazonaws/services/simpleworkflow/flow/WorkflowContext.java) to perform non backward compatible changes to workflow code without breaking running workflows.

Thanks a lot Maxim!

Hello!

Is there any documentation describing how "Continue as new" works in details?

The issue we are facing is that the WF waits on tasks that are delivered via signal, processes tasks and then restarts itself. Sometimes seems we are skipping a task while restarting. So we would like to understand details of restarting to implement it correctly.

Also is there any recommended practices on processing incoming tasks that can come in "burst" ie sometimes we can get multiple tasks while the first one is still being processed.

Thank you

As the WF actual restart happens when everything is completed, is there a way to execute a code right before WF restarts?
Specifically we would like to pass the parameters to the "new" WF at the time of actual restart ie when everything is completed

Edited by: Alex2 on Mar 10, 2019 6:21 PM

Is there any documentation describing how "Continue as new" works in details?
The issue we are facing is that the WF waits on tasks that are delivered via signal, processes tasks and then restarts itself. Sometimes seems we are skipping a task while restarting. So we would like to understand details of restarting to implement it correctly.
There are two parts of the picture. The service and the client behavior. From the service point of view continue as new is the same as completion, but with a new run of a workflow created atomically with the same id. The Java client expects all the code in the workflow function complete (using an enclosing TryFinally to ensure that) and then requests continue as new. Calls to a self client are not causing immediate continue as new execution, they just store arguments for the next run. These arguments are used later when the workflow function is done.

Also is there any recommended practices on processing incoming tasks that can come in "burst" ie sometimes we can get multiple tasks while the first one is still being processed.
There are multiple strategies depending on your requirements. For example the signal handler can add the task to the queue field of the workflow and the workflow function gets tasks from that queue and executes them. So if tasks come while processing they are just added to the queue.

As the WF actual restart happens when everything is completed, is there a way to execute a code right before WF restarts? Specifically we would like to pass the parameters to the "new" WF at the time of actual restart ie when everything is completed
You can use a TryFinally that wraps the rest of your workflow execution logic and call continue as new

Thank you very much, Maxim!
Can you please elaborate on how to "use a TryFinally that wraps the rest of your workflow execution" in presence of signal handler?

We ended up implementing it as follows:

Implement custom workflow worker down to AsyncDecider overriding getContinueAsNewOnCompletion to supply parameters at that point.
Signal handler just start a new task and puts the result promise to a list that AsyncDecider has access to.

You are correct that wrapping the workflow function in TryFinally is not going to help if a signal was received after the workflow function completion. But I think calling self client from the signal in this case still has to override the continue as new arguments.

In the new version of the Flow Framework (github.com/uber/cadence-java-client) I found a much better solution for this race condition. The basic idea is that if a signal is received after the workflow function completion the workflow code is rolled back and the signal is delivered before it is completed. This way having a try finally in the workflow code would provide such guarantee. The other nice property of the new framework that the workflow code is synchronous, so normal try/catch can be used.

We noticed an issues with the approach: even though the parent WF has child policy of "Terminate", if we terminate parent after the child continued as new, child is not terminated.

Is it possible to enforce child termination in this scenario?

Thank you

Weird. Sounds like a server side bug. I'm not sure what is the best way to report it as this forum apparently is not monitored by the AWS folks.

More details:

The child WF gets terminated, but after it continues as new again!