WEBVTT

00:00:00.035 --> 00:00:04.457
Open an event history in the Temporal
Web UI and the names are long.

00:00:04.540 --> 00:00:10.763
Activity Task Scheduled. Activity
Task Started. Activity Task Completed.

00:00:10.960 --> 00:00:12.365
There is a pattern in them,

00:00:12.365 --> 00:00:15.256
and it is worth a couple
of minutes of your attention.

00:00:16.053 --> 00:00:19.490
Every activity event begins
with the same two words.

00:00:19.687 --> 00:00:24.622
Cross those off, and what is left
is a state: Scheduled, in this case.

00:00:25.674 --> 00:00:30.980
That is the whole convention. It is not
a coincidence and it is not occasional.

00:00:31.177 --> 00:00:34.823
Every activity event
in the history is named this way.

00:00:35.620 --> 00:00:37.861
So here are the five you will meet.

00:00:38.058 --> 00:00:42.981
Scheduled and Started at the top,
then the three ways a task can end:

00:00:43.178 --> 00:00:46.360
Completed, Failed, and Timed Out.

00:00:47.156 --> 00:00:49.676
Five names, five states.

00:00:49.873 --> 00:00:53.205
And those five states
are not five separate ideas.

00:00:53.402 --> 00:00:55.339
They are three steps in one lifecycle,

00:00:55.422 --> 00:00:58.244
so the next thing
to do is lay that lifecycle out.

00:00:59.352 --> 00:01:01.464
Those five states are three steps,

00:01:01.547 --> 00:01:04.891
and an activity task always
takes them in the same order.

00:01:05.088 --> 00:01:10.058
Step one is Scheduled: the Temporal
cluster has put the task on a task queue.

00:01:10.254 --> 00:01:12.136
Nothing of yours has run yet.

00:01:12.932 --> 00:01:15.093
Step two is Started.

00:01:15.196 --> 00:01:16.924
A worker has polled that queue,

00:01:17.007 --> 00:01:21.106
taken the task off it,
and begun executing your activity code.

00:01:21.903 --> 00:01:25.918
Step three is a closed state,
and there are three of those.

00:01:26.001 --> 00:01:30.762
Completed, when the worker ran your code
all the way through and returned a value.

00:01:31.558 --> 00:01:35.205
Failed, when running your code
produced an error instead.

00:01:35.517 --> 00:01:40.023
And Timed Out, when the time allowed
ran out before any result came back.

00:01:40.936 --> 00:01:42.710
So Scheduled is always first,

00:01:42.793 --> 00:01:47.333
Started is always second, and one
of those three is always last.

00:01:47.530 --> 00:01:50.930
Anything else you see between them
in the history belongs to the workflow,

00:01:51.013 --> 00:01:52.569
not to this task.

00:01:53.366 --> 00:01:57.767
Once you can see those three steps,
the timeout names stop being jargon.

00:01:58.079 --> 00:02:00.681
Take the one called Start To Close.

00:02:00.877 --> 00:02:05.046
Its first half names step two,
the moment the worker began.

00:02:06.098 --> 00:02:08.268
Its second half names step three,

00:02:08.351 --> 00:02:11.405
whichever of those closed
states the task reaches.

00:02:11.509 --> 00:02:14.968
So the timeout is the longest gap
allowed between those two moments,

00:02:14.968 --> 00:02:16.467
and nothing else.

00:02:17.263 --> 00:02:18.344
A Start

00:02:18.796 --> 00:02:22.048
To Close of ten seconds says exactly this:

00:02:22.244 --> 00:02:26.817
once a worker picks the task up,
it has ten seconds to finish, to fail,

00:02:26.900 --> 00:02:28.839
or to be declared timed out.

00:02:29.636 --> 00:02:31.587
Read another one the same way.

00:02:31.784 --> 00:02:32.888
Schedule

00:02:33.084 --> 00:02:36.231
To Start spans step one to step two:

00:02:36.428 --> 00:02:40.063
how long the task may sit
on the queue before a worker picks it up.

00:02:40.976 --> 00:02:43.705
Every timeout
in Temporal is named this way:

00:02:43.809 --> 00:02:47.594
two points of that lifecycle,
and the stretch of time between them.

00:02:48.717 --> 00:02:52.618
Now, which of those three closed
states a task lands in is decided

00:02:52.618 --> 00:02:57.251
by two different parties, and the
split between them is not arbitrary.

00:02:58.303 --> 00:03:00.693
Completed and Failed
are the worker's call,

00:03:00.776 --> 00:03:04.783
and that is because the worker
is the thing actually running your code.

00:03:04.979 --> 00:03:10.297
If your activity function returns a value,
the worker reports the task as Completed.

00:03:11.210 --> 00:03:15.147
If it raises an error instead,
the worker reports Failed.

00:03:15.947 --> 00:03:20.452
Same worker, same process,
one difference in what your code did.

00:03:21.156 --> 00:03:23.688
Timed Out is the odd one out.

00:03:24.302 --> 00:03:29.005
That decision comes from the Temporal
cluster, and not from the worker at all.

00:03:29.918 --> 00:03:33.471
So why is the cluster the one
that decides a timeout?

00:03:34.086 --> 00:03:37.964
Think about what a timeout usually
means in a distributed system.

00:03:38.760 --> 00:03:40.862
Here is the ordinary case.

00:03:41.059 --> 00:03:44.772
A worker has taken the task
and started running your code,

00:03:44.855 --> 00:03:48.328
and the cluster is waiting
for it to report the result back.

00:03:49.380 --> 00:03:51.737
Now the worker process dies.

00:03:51.934 --> 00:03:56.300
It cannot finish the task,
so no Completed event is coming.

00:03:56.497 --> 00:04:00.956
It cannot hand you an error,
so no Failed event is coming either.

00:04:01.408 --> 00:04:03.789
It cannot report anything at all.

00:04:04.841 --> 00:04:07.883
The only party left
that can notice is the cluster.

00:04:08.196 --> 00:04:12.435
It knows when it handed the task out
and how long the task was allowed,

00:04:12.538 --> 00:04:13.699
so when that time is up

00:04:13.699 --> 00:04:18.274
with nothing received, the cluster
writes the timed out event itself.

00:04:19.187 --> 00:04:21.951
And that is the whole
responsibility model.

00:04:22.148 --> 00:04:25.048
The worker decides Completed or Failed,

00:04:25.131 --> 00:04:28.255
because it is the only one
that watched your code run.

00:04:28.568 --> 00:04:33.665
The cluster decides Timed Out, because it
is the only one still there to notice.

00:04:34.809 --> 00:04:38.757
One more thing, and it is the reason
any of this is worth learning.

00:04:38.954 --> 00:04:42.716
The same pattern runs straight
through workflow task events.

00:04:43.029 --> 00:04:46.954
Here are the activity events again,
with the state beside each one.

00:04:47.750 --> 00:04:50.525
And here are the workflow task events.

00:04:50.722 --> 00:04:54.496
Scheduled, when the cluster
puts a workflow task on a queue.

00:04:54.809 --> 00:04:58.490
Started, when a worker picks it
up and runs your workflow code.

00:04:59.287 --> 00:05:02.457
Then Completed,
when the worker is done with it.

00:05:02.653 --> 00:05:05.046
Failed, when the code raised.

00:05:05.359 --> 00:05:08.505
And Timed Out,
when the cluster stopped waiting.

00:05:09.557 --> 00:05:13.006
Two different kinds
of task, one vocabulary.

00:05:13.319 --> 00:05:17.960
The state column is the same on both
sides, and so is the division of labour:

00:05:18.044 --> 00:05:22.828
the worker reports completion or failure,
and the cluster declares the timeout.

00:05:23.532 --> 00:05:25.773
So there is nothing here to memorize.

00:05:26.086 --> 00:05:30.463
Read the suffix on an event, and it
tells you where that task had got to.

00:05:30.776 --> 00:05:32.852
Read the pair of names in a timeout,

00:05:32.936 --> 00:05:36.617
and it tells you which stretch
of that lifecycle the clock was watching.