Github user pnowojski commented on a diff in the pull request:
https://github.com/apache/flink/pull/6076#discussion_r190858003
--- 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 --
Thanks for the corrections! +1 for american version
I didn't want to make a definitive statement one way or the other, since I
think there always can be some special exceptions. Also, if user changes this
semantic because of reasons in his custom operator, then Flink will not brake,
it will have different semantic.
---
