BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20220421T163000Z
DTEND:20220421T173000Z
DTSTAMP:20220401T213815Z
ORGANIZER;CN=Clowder Events:mailto:c_m8k910vjcu6b4b7udo0kngo4d4@group.calen
dar.google.com
UID:3dah4
This is your daily summary of Beam's current P1 issues, not including flaky
tests
(https://issues.apache.org/jira/issues/?jql=project%20%3D%20BEAM%20AND%20statusCategory%20!%3D%20Done%20AND%20priority%20%3D%20P1%20AND%20(labels%20is%20EMPTY%20OR%20labels%20!%3D%20flake).
See https://beam.apache.
This is your daily summary of Beam's current flaky tests
(https://issues.apache.org/jira/issues/?jql=project%20%3D%20BEAM%20AND%20statusCategory%20!%3D%20Done%20AND%20labels%20%3D%20flake)
These are P1 issues because they have a major negative impact on the community
and make it hard to determin
I can confirm that changing input watermark to output watermark in
SimpleDoFnRunner.onTimer [1] seems to fix this. The question is, would
that have any other unintended consequences? It seems safe to me. It
still seems like the best option would be to use the actual output
timestamp here though.
I've dug into this some more and have a couple observations/questions:
- I added some logging to my DoFn in both @ProcessElement and @OnTimer, I
can confirm that I never have late data coming into ProcessElement
(element.timestamp() is never after the end of the window)
- The OnTimer method does en
