You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: arch_docs/workflow_task_chunking.md
+28-14Lines changed: 28 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,20 +4,20 @@ One source of complexity in Core is the chunking of history into "logical" Workf
4
4
5
5
Workflow tasks (WFTs) always take the following form in event history:
6
6
7
-
*\[Preceding Events\] (optional)
8
-
* WFT Scheduled
9
-
* WFT Started
10
-
* WFT Completed
11
-
*\[Commands\] (optional)
7
+
-\[Preceding Events\] (optional)
8
+
- WFT Scheduled
9
+
- WFT Started
10
+
- WFT Completed
11
+
-\[Commands\] (optional)
12
12
13
13
In the typical case, the "logical" WFT consists of all the commands from the last workflow task,
14
14
any events generated in the interrim, and the scheduled/started preamble. So:
15
15
16
-
* WFT Completed
17
-
*\[Commands\] (optional)
18
-
*\[Events\] (optional)
19
-
* WFT Scheduled
20
-
* WFT Started
16
+
- WFT Completed
17
+
-\[Commands\] (optional)
18
+
-\[Events\] (optional)
19
+
- WFT Scheduled
20
+
- WFT Started
21
21
22
22
Commands and events are both "optional" in the sense that:
23
23
@@ -32,8 +32,22 @@ There may be no events for more nuanced reasons:
32
32
rather as a "protocol message" attached to the task.
33
33
3. Server can forcibly generate a new WFT with some obscure APIs
34
34
35
-
Core does not consider such empty WFT sequences as worthy of waking lang (on replay - as a new
36
-
task, they always will), since nothing meaningful has happened. Thus, they are grouped together
35
+
## Handling of empty WFTs (March 2026)
36
+
37
+
Until now, Core would try to avoid waking lang when replaying empty WFT sequences (i.e. a WFT
38
+
Completed immediately followed by a WFT Scheduled and WFT Started, with no commands and no events
39
+
in-between), since they would presumably be no-ops and therefore waste execution resources. Instead,
40
+
the second WFT (and potentially subsequent WFTs) would be collapsed into the first, resulting in a
41
+
single WFT that has the inbound events and start time of the first WFT, but the resulting commands
42
+
of the last WFT in the collapsed sequence.
43
+
44
+
It was found that there are some particular edge cases where WFT collapsing might result in
45
+
incorrect replay behavior. One particular example of this is the case where an update request would
46
+
be sent after an empty WFT. This led to the development of some heuristics to avoid incorrect
47
+
chunking in presence of known problematic patterns. Unfortunately, it has been found that these
48
+
heuristics may
49
+
50
+
Thus, they are grouped together task, they always will), since nothing meaningful has happened. Thus, they are grouped together
37
51
as part of a "logical" WFT with the last WFT that had any real work in it.
38
52
39
53
## Possible issues as of this writing (5/25)
@@ -44,8 +58,8 @@ NDE.
44
58
45
59
### Possible solutions
46
60
47
-
* Core can attach a flag on WFT completes in order to be explicit that that WFT may be skipped on
61
+
- Core can attach a flag on WFT completes in order to be explicit that that WFT may be skipped on
48
62
replay. IE: During WFT heartbeating for LAs.
49
-
* We could legislate that server should never send empty WFTs. Seemingly the only case of this
63
+
- We could legislate that server should never send empty WFTs. Seemingly the only case of this
50
64
is
51
65
the [obscure api](https://github.com/temporalio/temporal/blob/d189737aa2ed1b07c221abb9fbdd28ecf68f0492/proto/internal/temporal/server/api/adminservice/v1/service.proto#L151)
0 commit comments