[
https://issues.apache.org/jira/browse/BEAM-14536?focusedWorklogId=776490&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-776490
]
ASF GitHub Bot logged work on BEAM-14536:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 31/May/22 18:21
Start Date: 31/May/22 18:21
Worklog Time Spent: 10m
Work Description: jrmccluskey commented on PR #17782:
URL: https://github.com/apache/beam/pull/17782#issuecomment-1142492381
The runner *should* never call TrySplit(0.0) but it's theoretically
possible, so proper handling in the case it does should be a good precaution.
Returning a ProcessContinuation without trying to claim any work is
definitely an anti-pattern as far as streaming SDFs are concerned. I'm confused
by the distinction between TryClaim(i) and isDataAvailable(i) though, as in
both cases once the position is claimed in the RTracker it won't be able to be
claimed after the checkpoint.
Issue Time Tracking
-------------------
Worklog Id: (was: 776490)
Time Spent: 1h 50m (was: 1h 40m)
> Offsetrange tracker panics when splitting at 0.0 without claiming work
> ----------------------------------------------------------------------
>
> Key: BEAM-14536
> URL: https://issues.apache.org/jira/browse/BEAM-14536
> Project: Beam
> Issue Type: Bug
> Components: sdk-go
> Reporter: Danny McCormick
> Assignee: Danny McCormick
> Priority: P2
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Right now, if you try to call TrySplit on an offsetrange restriction with a
> fraction of 0.0 and without first claiming work, it sets the primary
> restriction to \{Start, Start-1}. This causes newSplitResult to panic -
> https://github.com/apache/beam/blob/ff39fcb5229b15140e41a61bd09f7d590730e93a/sdks/go/pkg/beam/core/runtime/exec/sdf.go#L859
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
