Commit 606faf5
authored
Fixes instances where an activity heartbeat timeout would get "lost" (#771)
If, for any reason, the cached in-memory mutable state of a Workflow were to be reset (e.g. shard loading or transient persistent error), any in-flight activities w/heartbeats for that Workflow would lose their associated heartbeat timer tasks. In other words, it could result in an activity whose heartbeat has long expired, but which the server doesn't trying to re-schedule.
The fix is to populate the pendingActivityTimerHeartbeats map when loading the mutable state from the persistence layer if we have indicated that a heartbeat task has been created. This ensures that we don't have a pending activity without an in-memory record of a heartbeat when processing timer tasks.1 parent 1410257 commit 606faf5
File tree
3 files changed
+7
-4
lines changed- service/history
3 files changed
+7
-4
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
279 | 279 | | |
280 | 280 | | |
281 | 281 | | |
| 282 | + | |
| 283 | + | |
| 284 | + | |
| 285 | + | |
| 286 | + | |
282 | 287 | | |
283 | 288 | | |
284 | 289 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
824 | 824 | | |
825 | 825 | | |
826 | 826 | | |
827 | | - | |
828 | 827 | | |
829 | 828 | | |
830 | 829 | | |
| |||
835 | 834 | | |
836 | 835 | | |
837 | 836 | | |
838 | | - | |
| 837 | + | |
839 | 838 | | |
840 | 839 | | |
841 | 840 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
600 | 600 | | |
601 | 601 | | |
602 | 602 | | |
603 | | - | |
604 | 603 | | |
605 | 604 | | |
606 | 605 | | |
| |||
611 | 610 | | |
612 | 611 | | |
613 | 612 | | |
614 | | - | |
| 613 | + | |
615 | 614 | | |
616 | 615 | | |
617 | 616 | | |
| |||
0 commit comments