-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix lost diags across different mutators #2057
Conversation
6681198
to
94dbac2
Compare
If integration tests don't run automatically, an authorized user can run them manually by following the instructions below: Trigger: Inputs:
Checks will be approved automatically on success. |
@@ -40,6 +40,7 @@ func (m *resolveResourceReferences) Apply(ctx context.Context, b *bundle.Bundle) | |||
}) | |||
} | |||
|
|||
// Note, diags are lost from all goroutines except the first one to return diag |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shall we fix it instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know of an easy way - one would need to synchronize access to some common data structure - and I'd rather not invest a lot of time there - as this won't be necessary if move away from returning diags.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can't it just be as simple as
mu.Lock()
diags = diags.Append(...)
mu.Unlock()
inside the goroutine?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe - we can discuss offline. I'd consider this out of scope for this PR though (it does not need to be perfect, just incrementally better).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are more cases of using errgroup and diags together. So if we want to solve it properly, we should probably have some sort of abstraction that makes the usage foolproof.
However, like I said above, I'd rather not invest there because at this point it seems that the best abstraction is to call a function as soon as you have a diagnostic message, not accumulate them.
Changes
Fix cases where accumulated diagnostics are lost instead of being propagated further. In some cases it's not possible, add a comment there.
Tests
Existing tests