implement err group as an alternative to a wait group so errors from activities can be propagated upwards nicely#462
Conversation
…activities can be propagated upwards nicely
There was a problem hiding this comment.
Pull request overview
This PR adds a workflow-native ErrGroup (errgroup-style) abstraction so concurrent workflow coroutines can return errors that are aggregated and propagated via Wait, and includes a sample demonstrating the new API.
Changes:
- Expose
workflow.ErrGroupandworkflow.WithErrGroupas public workflow APIs. - Implement
internal/sync.ErrGroupwith tests for success and “first error wins”. - Add a new sample (
samples/concurrent-errgroup) demonstrating concurrent activity execution with error propagation.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
workflow/sync.go |
Exposes the new ErrGroup type alias and WithErrGroup helper at the workflow API layer. |
internal/sync/errgroup.go |
Implements the scheduler-compatible errgroup abstraction. |
internal/sync/errgroup_test.go |
Adds unit tests validating basic ErrGroup behavior. |
samples/concurrent-errgroup/concurrent_errgroup.go |
Demonstrates usage of workflow.WithErrGroup in a runnable sample. |
Comments suppressed due to low confidence (2)
internal/sync/errgroup.go:40
errGrouphas awaitingflag intended for misuse detection, but it’s currently unused beyond being set inWait. Either remove it to avoid dead state, or use it to enforce a clear contract (e.g., disallow callingGoafterWaitstarts, similar toWaitGroup).
This issue also appears on line 58 of the same file.
// track if Wait was called to detect certain misuses (optional)
waiting bool
internal/sync/errgroup.go:60
Waitsetswaiting=true, butGodoes not check it. This allowsGoto be called afterWaithas started/returned, which can makeWaitreturn without waiting for the newly launched coroutine (i.e., silent misuse). Consider adding a panic/guard inGowhenwaitingis already true (mirroringWaitGroup’s misuse detection) so incorrect usage fails fast.
func (g *errGroup) Go(f func(Context) error) {
g.n += 1
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // ErrGroup provides a way to run functions concurrently and collect the first error. | ||
| // | ||
| // It is conceptually similar to golang.org/x/sync/errgroup.Group but adapted to the | ||
| // workflow scheduler and Context. It cancels the derived Context when the first function | ||
| // returns a non-nil error. Wait waits for all functions to finish and returns the first | ||
| // error that was observed. If the Context passed to Wait is canceled before completion, | ||
| // Wait returns that context error instead. |
There was a problem hiding this comment.
The doc comment states that if the Context passed to Wait is canceled before completion, Wait returns that context error. But Wait blocks on g.done.Get(ctx) and Future.Get doesn’t observe ctx.Done()/ctx.Err(), so cancellation won’t unblock Wait. Please update the comment to match behavior, or make the wait cancellation-aware.
| ctx Context | ||
|
|
||
| // track if Wait was called to detect certain misuses (optional) | ||
| waiting bool |
There was a problem hiding this comment.
the copilot code review comment about this seems accurate, do we need to check that?
There was a problem hiding this comment.
yeah good point, modified the doc string to match actual behavior.
also wired up the waiting flag to panic on calling Go after Wait, which is consistent with WaitGroup#Add.
Future.Get does not observe ctx.Done, so the doc comment promising cancellation-aware Wait was incorrect. Aligns with WaitGroup behavior. Also wires up the waiting flag to panic on Go called after Wait, matching the WaitGroup.Add misuse detection pattern.
DerkSchooltink
force-pushed
the
feature/implement-err-group
branch
from
b0a3bae to
8968430
Compare
implement #461