lostluck commented on code in PR #40879:
URL: https://github.com/apache/beam/pull/40879#discussion_r4428450380
##########
model/pipeline/src/main/proto/org/apache/beam/model/pipeline/v1/beam_runner_api.proto:
##########
@@ -1361,20 +1364,52 @@ message TimeDomain {
// from a GroupByKey or CombinePerKey
//
// A trigger is described in terms of when it is _ready_ to permit output.
+//
+// Triggers are evaluated per key and window. Each time the root trigger is
+// ready, it fires and the current pane is output.
+//
+// Finishing triggers and closed windows:
+//
+// Some triggers may "finish", meaning they will never be ready again. When
+// the _root_ trigger of a window finishes, that window is closed for its key:
+//
+// * The firing that finished the trigger produces the final pane for the
+// window (its PaneInfo has is_last set).
+// * No further panes are produced for the window. In particular, there is no
+// additional pane when the watermark passes the end of the window or when
+// the window expires (end of window + allowed lateness), regardless of
+// ClosingBehavior or OnTimeBehavior.
+// * Any elements that arrive for the window after it has been closed are
+// dropped. This applies whether or not those elements are late relative to
+// the watermark.
+//
+// A root trigger that may finish before the window expires can therefore lose
+// data. SDKs typically call such triggers "unsafe". Wrapping a trigger in
+// Repeat makes it never finish. Runners must still implement the closed-window
+// semantics above for pipelines that use finishing triggers.
+//
+// A subtrigger that finishes does not by itself close the window; it only
+// affects its parent trigger, as described for each trigger type below.
message Trigger {
// Ready when all subtriggers are ready.
+ //
+ // Finishes after it fires once.
Review Comment:
Well that makes sense, since I mostly cribbed from the Python SDK for that,
as the Java one was very difficult to follow as I recall (too many abstraction
points). The trick is on non-finishing (eg repeatable) subtriggers I guess.
Triggers, not as well formed as we like, use State and Timers instead.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
