[
https://issues.apache.org/jira/browse/BEAM-14239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17530068#comment-17530068
]
Reuven Lax commented on BEAM-14239:
-----------------------------------
This is a fairly serious bug - it completely violates Beam's timer semantics.
I'm not sure off the top of my head how to fix it - the timerStillPresent map
is only really stored in memory for the current bundle. The tag is what
uniquely identifies the timer. We should not be encoding timestamps into that
tag, but if we don't then we have know way of retrieving the output timestamp
when the timer fires.
> Changing the output timestamp of a timer does not clear the previously set
> timer
> --------------------------------------------------------------------------------
>
> Key: BEAM-14239
> URL: https://issues.apache.org/jira/browse/BEAM-14239
> Project: Beam
> Issue Type: Bug
> Components: runner-dataflow
> Affects Versions: 2.37.0
> Reporter: Steve Niemitz
> Priority: P1
> Attachments: image-2022-04-04-09-57-29-583.png
>
>
> While looking into an unrelated bug with GroupIntoBatches, I noticed that it
> seems like changing the output timestamp of a timer does not clear the
> existing timer, and instead creates a new one.
> This kind of makes sense looking at the implementation of timers in Dataflow,
> the output timestamp is encoded into the timer ID, but this is not reflected
> in the timerStillPresent map in WindmillTimerInternals. It seems like it
> should be, and the previous timer should be deleted.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
