Go samples - recovery example exception

Hi All,

I am having trouble understanding the recovery example.
recovery example

I don’t think I understand fully on what’s happening. Would highly appreciate if the README or the comments on the code could be enhanced a bit?

Particularly concept around code blocks like below is new and I could not find documentations around these.

recovery_workflow.ggo:

// Setup retry policy for recovery activity
	info := workflow.GetInfo(ctx)
	expiration := info.WorkflowExecutionTimeout
execution := &commonpb.WorkflowExecution{
		WorkflowId: workflowID,
	}

Also while running the example, at the invocation of the recovery workflow, i get two error. Not sure if this was normal or I am missing something.

I can see the previous workflow gets terminated and new one gets created. However, in the new one: i don’t see the counter value got updated. It is showing the count value as 1, although i have sent 5 signals.

I was looking at this particular sample with a view to design something similar as below:

  • A workflow with a number of activities where each activity will make an outbound API call.
  • Parts of the response from Activity 1 will be used as an input for the second API call (Activity 2).
  • Now if due to some reason, that payload in the second Activity get a 500 response, the task should fail and wait at that stage without failing the workflow.
  • A query will be used to understand the problem.
  • Then based on the payload analysis outcome, a human operator will manually fix that payload probably via signal and/or fix the DB and then re-trigger that activity.

Would really appreciate if anyone can point to any similar go based samples for above case.

/RW

Also while running the example, at the invocation of the recovery workflow, i get two error. Not sure if this was normal or I am missing something.

Thanks for reporting, it was indeed a bug in sample, pr with fix here.

  • Merged - you can fetch from main branch and should work now :slight_smile:
1 Like

// Setup retry policy for recovery activity
info := workflow.GetInfo(ctx)
expiration := info.WorkflowExecutionTimeout

workflow.GetInfo(ctx) extracts info of a current workflow from the workflow context.
This allows you to get the workflow starting configs etc, see here.

execution := &commonpb.WorkflowExecution{
WorkflowId: workflowID,
}

This creates a WorkflowExecution which identifies a specific running workflow by its workflow id . In Temporal you can only have one running workflow with the same workflow id running at any time, so it would pick up the currently running one. WorkflowExecution is then used in GetWorkflowHistory command that gets its workflow history.

I was looking at this particular sample with a view to design something similar as below:

  • A workflow with a number of activities where each activity will make an outbound API call.
  • Parts of the response from Activity 1 will be used as an input for the second API call (Activity 2).

We don’t have a sample that makes a rest api call to some third party services but you could implement that yourself given the api you want to use in your activity.

There is a number of examples that execute and activity sync and assign the result, for example:

var res string
err := workflow.ExecuteActivity(ctx, activities.MyActivity).Get(ctx, &res)
// use res to pass as input to your next activity execution call
// ...
  • Now if due to some reason, that payload in the second Activity get a 500 response, the task should >fail and wait at that stage without failing the workflow.
  • A query will be used to understand the problem.
  • Then based on the payload analysis outcome, a human operator will manually fix that payload > probably via signal and/or fix the DB and then re-trigger that activity.

In case of a bad result, you could return a NewNonRetryableApplicationError from your activity and then wait for a signal with the next payload to invoke this activity with again. For the query part, see this sample.
Another options could be to poll until your receive a valid response, see this post for best practices for that.
Hope this helps you get started.

1 Like

Thank you Tihomir