Hi, Does it make sense to create workflows that only sleep?
We’re in the insurance business and we are hesitating how to use Temporal for the following scenario:
When we create a policy, we have several points in time where where we want to verify that an action has been made. So our flow is:
Wait until T1 and verify that a payment was made by then.
Wait until T2 and verify that a document was signed by then.
Likewise wait for other times and verify some action.
When we reach T1 (or T2/T3…) we check if the condition was met. If not we execute some actions (like sending emails, update the DB) and then wait again until a new point in time T1_1 and then execute another action.
My question is: Does it makes sense for us to create a workflow for each time slot that only sleeps() and when waken up, check a condition, and possibly starts a new workflow (that again, sleeps and after waking up may start a new workflow).
So when a policy is created, we will start new workflows:
WaitT1ForPaymentWorkflow()
WaitT2ForDocumentWorkflow()
WaitT3ForUserActionWorkflow()
and then we might create new similar workflows in the future, depends on what happned
Also, is there an option to programmatically check for a given workflow, until what point in time it is sleeping? I was thinking of using a Query handler, but was wondering if there is already an API for this.
I don’t see a problem with this offhand (maybe someone else will see something). One thought is might you like to have one high-level “policy implementation” workflow that would run for the duration of the policy, and itself keep track of your T1, etc. time points? At time T1, etc. it could check the condition and start the child workflow if needed. But there’s nothing wrong with having a separate “WaitT…” workflows which each sleep for a long time and then check their condition.
programmatically check for a given workflow, until what point in time it is sleeping?
I don’t know if this is possible or not… but you can run multiple sleep timers in a workflow if you want to, so I think this would be fragile solution (you’d have to figure out which sleep timer you wanted, and ensure you kept that code up to date with respect to changes you might make to the workflow in the future). I think a Query would be better.
Also look at updateable timer example, can help if you need to change sleep time to trigger processing faster (or delay it more).
Also, is there an option to programmatically check for a given workflow, until what point in time it is sleeping?
You can calculate it from executions event history, or as mentioned write the time you intend to sleep before sleep to workflow state and could get it via workflow query.
Note that if your workers are not up when sleep timer fires, this sleep can become longer (timer fired event would be delivered to your workers when they are back up and start polling)
I thought Eytan meant that they would be running new “WaitT…” workflows for each policy (not for example having one “WaitT1ForPaymentWorkflow” which would check all the policies). I think then they wouldn’t need continue-as-new?
My first idea was indeed to use a different workflow for each point in time in the future.
But when considering Andrew’s suggestion:
to have one high-level “policy implementation” workflow that would run for the duration of the policy, and itself keep track of your T1, etc. time points?
Is there a reason to use continueAsNew if we do not expect the event log to over populate?
The idea is to have one consistent workflow for the lifetime of the poilcy which will initiate new short term workflows for ad hoc tasks.
