[ 
https://issues.apache.org/jira/browse/BEAM-10976?focusedWorklogId=735242&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-735242
 ]

ASF GitHub Bot logged work on BEAM-10976:
-----------------------------------------

                Author: ASF GitHub Bot
            Created on: 02/Mar/22 11:44
            Start Date: 02/Mar/22 11:44
    Worklog Time Spent: 10m 
      Work Description: damccorm commented on a change in pull request #16980:
URL: https://github.com/apache/beam/pull/16980#discussion_r817612803



##########
File path: sdks/go/pkg/beam/core/runtime/exec/pardo.go
##########
@@ -220,6 +226,49 @@ func (n *ParDo) FinishBundle(_ context.Context) error {
        return nil
 }
 
+func (n *ParDo) FinalizeBundle(ctx context.Context) error {
+       failedIndices := []int{}
+       for idx, bfc := range n.bf.callbacks {

Review comment:
       I definitely agree that this is a better approach and will update 
accordingly. With that said:
   
   > You'll note that in Go, that it's not a great idea to simply add new 
methods to an interface, as it will break everything that's trying to implement 
the interface.
   
   Something I'm a little unclear on is what guarantees we actually make about 
compatibility outside of the `beam` package. Are we basically saying that we 
can't change _any_ of our internal interfaces/function definitions? As best I 
could tell, `Unit` isn't something we actively expose to users through any 
normal path. I know we don't at this time have a true concept of internal for 
most of our stuff, but I'm curious how we make decisions on where its ok to 
make changes like this




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


Issue Time Tracking
-------------------

    Worklog Id:     (was: 735242)
    Time Spent: 1h  (was: 50m)

> Enable Bundle Finalization in Go SDK
> ------------------------------------
>
>                 Key: BEAM-10976
>                 URL: https://issues.apache.org/jira/browse/BEAM-10976
>             Project: Beam
>          Issue Type: Sub-task
>          Components: sdk-go
>            Reporter: Robert Burke
>            Assignee: Danny McCormick
>            Priority: P3
>          Time Spent: 1h
>  Remaining Estimate: 0h
>
> Eg. to support acking pubsub/kafka messages as processed after the results 
> have been properly committed by the runner.
> Note, that due to BEAM-10959 that when implementing this, an instruction must 
> remain "active" until it's finalization occurs as well. Specifically, we 
> should probably keep another map around for "to be finalized" process bundle 
> instructions so we can return the appropriate "empty" response and not 
> accidently evict them from the nearly equivalent inactive state until after 
> finalization.
> [https://s.apache.org/beam-finalizing-bundles]
>  
> (To be updated once [https://github.com/apache/beam/pull/13160] is merged and 
> the programming guide updated with SDF content.)
> See also Java and Python approaches
> https://beam.apache.org/documentation/programming-guide/#bundle-finalization



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Reply via email to