Github user alpinegizmo commented on a diff in the pull request:
https://github.com/apache/flink/pull/6076#discussion_r190841061
--- Diff: docs/dev/event_time.md ---
@@ -219,4 +219,17 @@ with late elements in event time windows.
Please refer to the [Debugging Windows & Event Time]({{ site.baseurl
}}/monitoring/debugging_event_time.html) section for debugging
watermarks at runtime.
+## How operators are processing watermarks
+
+General rule is that operator are required to completely process a given
watermark before forwarding it downstream. For example,
+`WindowOperator` will first evaluate which windows should be fired and
only after producing all of the output triggered by
+the watermark, the watermark itself will be handled downstream. In other
words, all elements produced due to occurrence of
+the watermark will be emitted before such watermark.
+
+Same rule applies to `TwoInputStreamOperator`. However in this case
current watermark of the operator is defined as a minimum
+of both of it's inputs.
+
+Details of this behaviour is defined by implementations of methods
`OneInputStreamOperator.processWatermark`,
+`TwoInputStreamOperator.processWatermark1` and
`TwoInputStreamOperator.processWatermark2`.
+
--- End diff --
As a general rule, operators are required to completely process a given
watermark before forwarding it downstream. For example,
`WindowOperator` will first evaluate which windows should be fired, and
only after producing all of the output triggered by
the watermark will the watermark itself be sent downstream. In other words,
all elements produced due to occurrence of a watermark will be emitted before
the watermark.
The same rule applies to `TwoInputStreamOperator`. However, in this case
the current watermark of the operator is defined as the minimum
of both of its inputs.
The details of this behavior are defined by the implementations of the
`OneInputStreamOperator.processWatermark`,
`TwoInputStreamOperator.processWatermark1` and
`TwoInputStreamOperator.processWatermark2` methods.
---
