proposal: x/sync/errgroup: optionally collect all errors

[imjasonh]

Proposal Details

When using errgroup.Group, the current behavior is to fail and return the first error that's encountered. This works great. errgroup is consistently one of my favorite packages to use.

But, sometimes I want to collect and report all errors at the end.

Luckily, we have errors.Join to do just this!

I'd like to propose either an optional method to make errgroup collect errors, or a type/package/something to do what errgroup does, with this behavior.

I'm open to any naming or structure you folks would recommend, and I'd be happy to send a CL to implement it if there's interest.

[apparentlymart]

If I'm understanding correctly I think this is the same as what I asked in #57534 (comment), and the errgroup author responded in #57534 (comment) with a justification against this idea.

I don't have a strong feeling about this myself; I'm just sharing this to link the discussions together.

[gabyhelp]

Related Issues

• proposal: x/sync: change errgroup to return a wrapped error instead of only the first #60415 (closed)
• x/sync/errgroup: get all errors #23595 (closed)
• proposal: sync: add golang.org/x/sync/errgroup #57534
• x/sync/errgroup: add TryGo and SetLimit to control concurrency #27837 (closed)
• proposal: x/sync/errgroup: Additional goroutines should not be started after the context is cancelled #61611 (closed)
• sync: Proposal: Add a Go() function to sync.WaitGroup #23538 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[ianlancetaylor]

@apparentlymart I think this suggestion is slightly different. Rather than having a Wait method that joins together all the errors, we leave the Wait method doing what it does today: return the first error. The proposal here is a new method, WaitAll, that waits for all the errors and returns them joined together with errors.Join. That is, Wait is useful and we provide it today, and @bcmills was arguing that we should keep Wait. But having Wait behave as it does is not necessarily an argument against also providing WaitAll.

[seankhliao]

There's a more recent objection to having a method get all of them
#57534 (comment) :

that would make the storage requirement of an errgroup O(N) with the number of tasks processed instead of O(1) as it is today.
In typical errgroup usage, all errors after the first will be caused by the cancellation triggered by the first error, and thus unreliable. Moreover, since Go calls may be made concurrently there is no obvious order of results, and thus no obvious way to collate them or correlate them with the associated Go calls.

[ianlancetaylor]

Thanks, that is convincing. We aren't going to do this. @imjasonh This might be suitable for a different package, but it should probably start out as a third-party package rather than one in x/sync. Thanks.

[imjasonh]

Thanks, I appreciate your consideration and discussion.