Code walkthrough

In this video, you will see how a Temporal Workflow Execution works by examining the code from the farewell-workflow exercise.

As you have learned, a Worker executes your Workflow and Activity code, so a Workflow Execution cannot progress unless at least one Worker is running.

Take a look at the code for a Worker. This is the worker.ts file, and I'll go section-by-section through the code to explain what is happening.

At the top of the file, there are two import statements. Since this example is written in TypeScript code, the program begins by importing its dependenices. The first dependency is the Worker from the Temporal TypeScript SDK, and the second is the Activities that you have defined in your activities.ts file.

Next is the run function. This function creates a new Worker Entity and then runs the new Worker.

A Worker executes Workflow and Activity Tasks for types that are registered with it. In this Worker, you registered the Workflow defined in the workflows file, and all functions from the Activities module. You also specified the name of the Task Queue, translation-tasks.

When you launch the Worker with the command npm run start.watch, you create a new Worker process with a Worker entity and a Temporal Client which opens a long-lasting connection to the Temporal Cluster, which it uses to continuously poll for new tasks. Although the Worker is running, the Workflow is not, so the task queue is empty and the Worker has nothing to do.

The farewell-workflow exercise has two Workflow Definitions: one called greeting and another called farewell. I'll show the greeting Workflow first.

To run the Workflow, you will use the Client. This is the greeting.ts file in the clients directory. First, you create a new Client that will communicate with the Temporal Cluster.

Then, you start your Workflow from code within your own application by calling client.workflow.execute with your input, in this case the greeting Workflow. You also specify the arguments to pass to your Workflow, in this example the string "Tina," the name of the Task Queue, and a unique identifer for this Workflow.

When you run this code with the command npm run greeting, the Temporal Cluster records a new Event into the Event History of this Workflow Execution. WorkflowExecutionStarted is always the first Event.

As I continue with my explanation, pay attention to the Event History shown on the right. Additional events will begin appearing below this one as the Workflow Execution progresses. I won't mention all of them, but I highlight them in yellow when they first appear so they're easier to spot. You can also find these events for each Workflow Execution in the Temporal UI.

The Temporal Cluster adds a Workflow Task to the Task Queue and records another event, WorkflowTaskScheduled, into the Event History. Its name follows a pattern: when a new Task is added to the queue, the name ends with "Scheduled."

Since the Worker Process has capacity to do some processing work, it accepts this new Task. This results in a new Event, WorkflowTaskStarted. When a Worker dequeues a Task, the Cluster generates an event whose name ends with "Started."

The Worker Process begins the Workflow Task by invoking the function from the Workflow Definition. It continues by running the code within this function.

Back to the client code. client.workflow.execute.

A few important things happen as a result of the executing the greeting workflow. The Worker can't make further progress on the Workflow until the Activity Execution concludes, so it notifies the Cluster that the current Workflow Task is complete. In response, the Cluster adds a new Event to history. The Worker also sends a command to the cluster requesting it to schedule an Activity Task.

The Temporal Cluster creates an Activity Task and adds it to the Task Queue, resulting in a new Event.

Since the Worker Process has capacity to perform additional work, it accepts the Activity Task.

The Worker Entity now invokes the function corresponding to the Activity Definition for the getSpanishGreeting Activity.

The Worker then runs the code within the function. In this case, the Activity issues a request to the microservice.

This request was successful and the service responds by providing a customized greeting in Spanish.

When the Activity function returns, the Worker notifies the cluster that the Activity Task is complete, resulting in a new Event. Since there is only one Activity in this Workflow and the function returns, the Temporal Cluster adds a new Workflow Task to the queue.

When the Worker accepts this new Task, the Temporal Cluster adds a WorkflowTaskStarted Event to the history. The Worker continues where it left off, executing the remaining statements in the Workflow Definition, and logs WorkflowExecutionCompleted when everything is done.

It is now time to execute the farewell Workflow. The command npm run farwell executes the code in the farewell.ts file.

The original Worker process is still running, and the Temporal Client is continuously polling for new tasks, so it sees the new Workflow Execution request, accepts the Workflow Task, completes the Workflow Task and schedules the getSpanishFarewell Activity Task.

Let's take a moment to look at a failure scenario. What happens if the Worker crashes; for example, because it ran out of memory?

You can recover from this by restarting the Worker or launching a new Worker on a different machine. In either case, Temporal will automatically recreate the state of the Workflow up to the point of failure, so progress will continue on from there, as if the Worker never crashed at all.

Activities that completed successfully before the crash won't be executed again; instead, Temporal reuses the values returned by their previous executions.

When the Worker accepts the Activity Task. The Temporal Cluster adds ActivityTaskStarted to the Event History.

But what if that microservice went offline just before the request? In this case, the request would fail, ultimately causing the Activity function to return the error from Axios.

The default behavior in Temporal is for a failed Activity to be automatically retried, with a short delay, until it succeeds or is canceled. You can customize this behavior with a Retry Policy.

Through a retry, the Worker invokes the Activity function again, which in turn calls out to the microservice.

For this example, let's assume that the service outage was an intermittent failure, so the request made during the retry is successful.

Since the service is now back online, it responds to our latest request and provides the requested farewell message.

When the function returns, the Worker notifies the Temporal Cluster that the Activity Task is complete.

There are still a few lines of the Workflow code that haven't been run yet, so the Temporal Cluster adds a new Workflow Task to the queue.

When the Worker accepts this new Task, the Temporal Cluster adds a WorkflowTaskStarted Event to the history. The Worker continues where it left off, executing the remaining statements in the Workflow Definition.

Once this function returns, the Workflow Task is complete.

The Worker continues polling for new Tasks, but there is no more work related to this Workflow Execution.

The client application, which has been awaiting the result of the Workflow Execution because it's blocked, will now receive that value.

The cluster provides the result to the application, which can process it however it wishes, and the Workflow begins it's final set of actions, ending with WorkflowExecutionCompleted.

In this video, you saw what happens during two Workflow Executions, and learned about how Temporal handles failure situations.