1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
//! Describe-workflow response projection.
//!
//! The ops console's `POST /workflows/describe` read consumes exactly this shape:
//! a workflow [`WorkflowSummary`] projection plus the run's event [`Event`]
//! history as plain JSON. Defining it here lets the same type be exported to
//! TypeScript (so the generated bindings match the wire by construction) and be
//! produced directly by the HTTP handler at the transport boundary.
use ;
use ;
use crate::;
/// Response to a describe-workflow request.
///
/// `history` is the run's events as plain serialized [`Event`] values (never a
/// protobuf-derived envelope), so the ops console decodes each entry directly.
/// When `include_history` is false the server returns an empty `history`.
///
/// `unserved` is computed independently of `include_history`: it is the answer
/// to "can anything still advance this run", and an operator who asked for the
/// summary alone still needs it.
/// One generation boundary: the sequence at which a `WorkflowStarted` opened
/// `run_id`.
///
/// Only `WorkflowStarted` opens a generation. `WorkflowReopened` also carries a
/// `run_id`, but it names the run it REOPENS rather than beginning a new one, so
/// treating it as a boundary would state the same fact twice and would misread a
/// reopen that arrives out of order.
/// One in-flight activity whose recorded dispatch address is not being served.
///
/// The activity's identity, address, and dispatch instant come from the run's
/// own recorded history; the verdict and the counts come from the live
/// connected-worker fleet at read time. Both halves are named so an operator can
/// see which is which.