je-ik commented on pull request #14718: URL: https://github.com/apache/beam/pull/14718#issuecomment-847575729
The hold part might not be part of conceptual model, but the output timestamp has direct implications, that involve it. The reason is in the underlying invariant - if element arrives ahead of watermark, it should stay ahead of watermark throughout the whole computation, if possible (the same holds true for droppable data). Therefore, if a timer sets output timestamp for earlier timestamp than the fire timestamp and the output timestamp is ahead of output watermark, it simply implies watermark hold, otherwise the element might be output after the output watermark, causing it to be late (or even droppable). When it comes to timers that are set for time interval between (endOfWindow, windowGcTime) the situation is different. There is no way to infer if there should, or should not be a watermark hold (assuming we enforce the output timestamp to be within the bounds of window), because the situation is exactly the same - fire timestamp for windowGc time, output timestamp endOfWindow. There has to be explicit user-code declarations of this. (e.g. `timer.withLateOutputTimestamp(...)`, as opposed to `timer.withOutputTimestamp`, which would have the semantics "withOnTimeOutputTimestamp"). Conclusion from my side - if we want to implement c) we need a deeper change to the timer API, it is definitely not about adding/removing/modifying a few preconditions, we should solve it in different JIRA. Please stop me, if my conclusions are wrong, otherwise I'll merge this tomorrow - just to make it explicit, this PR is the option b) from the options above. -- 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. For queries about this service, please contact Infrastructure at: [email protected]
