This seems like just a bug. If you set a timer for X and have output timestamp Y where X < Y this should be fine. Is the problem the current input watermark? Are you trying to set a timer with output timestamp that is already past? I think that should be allowed, too, as long as the window is not expired, but I may be missing something.
Some greater detail would be useful - maybe the full stack trace and/or a failing unit test in a PR? Kenn On Thu, Apr 29, 2021 at 12:51 AM Jan Lukavský <je...@seznam.cz> wrote: > Hi, > > I have come across a bug with timer output timestamp - when using event > time and relative timers, setting the timer can arbitrarily throw > IllegalArgumentException if the firing timestamp (input watermark) is > ahead of the output timestamp (like .java.lang.IllegalArgumentException: > Attempted to set an event-time timer with an output timestamp of > 2021-04-29T07:16:19.369Z that is after the timer firing timestamp > -290308-12-21T19:59:05.225Z). But there is no way to access the firing > timestamp from user code. This means that the use has to either catch > the IllegalArgumentException, or not use this construct at all. > > Catching the exception should probably not be part of a contract, so we > should do one of the following: > > a) either throw the exception right away and disable using relative > timers with output timestamp completely, or > > b) support it correctly > > What is the actual reason not to support output timestamps, that are > ahead of firing timestamp? From my understanding, that should not be an > issue, because there is TimestampCombiner.EARLIEST on the > watermarkholdstate that corresponds to the output timestamp. If that is > correct can we simply remove the check? > > Jan > >
