One reason is the lack of `elem` used here: https://github.com/apache/beam/blob/15048929495ad66963b528d5bd71eb7b4a844c96/runners/core-java/src/main/java/org/apache/beam/runners/core/SimpleDoFnRunner.java#L440
That might be the whole reason. Still, your point is a good one that the sort of validation is different. The check for timestamp skew dates back to even before Beam and has been a source of various troubles. It is also probably obsolete. The purpose was really to make sure elements did not fall into time intervals that would be dropped immediately. Now that element dropping is associated with expired windows, it may be entirely obsolete or just ready for some updating. +Lara Schmidt <laraschm...@google.com> is the person who has looked in detail most recently, I think. Kenn On Wed, Feb 2, 2022 at 8:00 AM Evan Galpin <evan.gal...@gmail.com> wrote: > Hey folks, > > I noticed through tracing code that when calling > ProcessContext#outputWithTimestamp, the method checkTimestamp is > invoked[1]. However, no similar check appears to be invoked when calling > FinishBundleContext#output, which explicitly requires passing a timestamp > as one of the arguments[2]. Instead, all that's checked is that the pane > and timestamp are not null. Is this difference intentional? Could someone > help me improve my understanding? > > Thanks, > Evan > > [1] > https://github.com/apache/beam/blob/15048929495ad66963b528d5bd71eb7b4a844c96/runners/core-java/src/main/java/org/apache/beam/runners/core/SimpleDoFnRunner.java#L422 > [2] > https://beam.apache.org/releases/javadoc/2.35.0/org/apache/beam/sdk/transforms/DoFn.FinishBundleContext.html#output-org.apache.beam.sdk.values.TupleTag-T-org.joda.time.Instant-org.apache.beam.sdk.transforms.windowing.BoundedWindow- >
