Confused about the number of history events generated by the money transfer template

Hello, I am new to temporal and have just tried the money transfer example. Everything went smoothly. However, I need some help in understanding what are the events being generated. On running the workflow once, 17 history events are generated.

Here’s what I see in summary

  1. WorkflowExecutionStarted

  2. WorkflowTaskScheduled (MONEY_TRANSFER_TASK_QUEUE)

  3. WorkflowTaskStarted

  4. WorkflowTaskCompleted

  5. ActivityTaskScheduled (Withdraw)
    with activityId 8fb3d3a6-bf6f-35a5-b6fc-35142b24f759, but I don’t see a reference to this below

  6. ActivityTaskStarted
    I don’t see any mention of activityId here in the details, so I presume this is for the activity that was just scheduled.

  7. ActivityTaskCompleted

  8. WorkflowTaskScheduled (82717@Animeshs-MacBook-Pro.local:d3378743-f9bb-4fa6-aee3-9d1b3abba16)

  9. WorkflowTaskStarted

  10. WorkflowTaskCompleted

  11. ActivityTaskScheduled (Deposit)

  12. ActivityTaskStarted

  13. ActivityTaskCompleted

  14. WorkflowTaskScheduled (82717@Animeshs-MacBook-Pro.local:d3378743-f9bb-4fa6-aee3-9d1b3abba16)

  15. WorkflowTaskStarted

  16. WorkflowTaskCompleted

  17. WorkflowExecutionCompleted

I am confused about the following sequences of events

Steps 2 to 4: Why the workflow task in MONEY_TRANSFER_TASK_QUEUE got scheduled, started and completed within these steps, the activities haven’t even started yet

Steps 8 to 9 and Steps 14 to 17: What is this series of workflow tasks that get started and completed outside of the activity run boundary

Would really appreciate some help on understanding this better.


Welcome to the Temporal community!

Temporal workflows are specified using code. So every time there is a new event like activity completion the workflow code has to be consulted for a list of commands to execute.

In Temporal activities and workflows are hosted by external processes which are called workers. These processes listen (using long poll) on so-called task queues. There are two types of task queues: workflow and activity ones. Even if they use the same name they are completely separate.

When an activity task is received the activity implementation is invoked.

When a workflow task is received the workflow makes progress based on new events and new commands are sent to the service.

A workflow task (in a happy case) goes through the following states:

  1. WorkflowTaskScheduled when it is created and added to the workflow task queue
  2. WorkflowTaskStarted when it is picked up by a workflow worker process
  3. WorkflowTaskCompleted when workflow cannot make any new progress and the list of commands to execute is sent to the service.

An activity task is pretty similar:

  1. ActivityTaskScheduled when activity execution is requested and a correspondent task is added to an activity task queue.
  2. ActivityTaskStarted when an activity worker received it.
  3. ActivityTaskCompleted when activity result is reported to the service.

Note that when an activity completes and the ActivityTaskCompleted is recorded the service needs to consult workflow code about the next steps. That’s why a workflow task is immediately scheduled.

Thanks maxim!

that makes sense. so here’s my next doubt -

I am guessing it is safe to assume that within one workflow, when an activity task is started, it must first be completed before moving on to the next activity task? is there any way (or need) to run parallel activity tasks?

My question stems from steps 5 to 7 - when an activity task is scheduled, assuming a non-error case scenario, the next events that follow will be that the activity task gets started and activity task gets completed.

I can’t see any id to tie these three events together. steps 6 and 7 seem to have a scheduledEventId, but that is not mentioned anywhere in the step 5 (ActivityTaskScheduled)

Attaching a screenshot for reference

Ok I think the eventIds are available in the full JSON logs. That makes things clear.

ActivityTaskScheduled is the first event related to the activity. All others reference it through scheduledEventId.