-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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 race condition when reloading configuration #32433
Conversation
This will close #32337 when merged |
Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane) |
The 8.3.3 build candidate was generated earlier this morning. If we want this in the 8.3 release we need to raise it as a blocker on the release scheduled for next week and have a new build candidate generated. Otherwise this won't be fixed until the 8.4 release at the end of August. @belimawr should I raise this as a blocker for 8.3.3 to have the build candidate regenerated? |
defer wg.Done() | ||
runner.Stop() | ||
r.logger.Debugf("Runner: '%s' has stopped", runner) | ||
}() | ||
}(runner) |
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 wish the linter would have caught this...
Am I correct that this means some running modules will never actually be stopped depending on the timing? This definitely feels like something we should include in the 8.3.3 release.
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 wish the linter would have caught this...
Am I correct that this means some running modules will never actually be stopped depending on the timing? This definitely feels like something we should include in the 8.3.3 release.
Yes, it does. Without this PR, the situation is worse then the original bug 😢
But the original buggy PR is very recent, so I strongly believe no releases were made in the mean time.
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 wish the linter would have caught this...
Me too, there should be a linter for that. It's such a basic case of variable shadowing...
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.
Go vet can do it but it is disabled by default: https://golangci-lint.run/usage/linters/#govet
Probably it will be noisy but I can try turning it on and see what result it gives me.
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 tried to run go vet
but for some reason it didn't detect it. I even tried go vet -loopclosure
, still not error shown :/
But I didn't spend much time trying to get it working
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 tried to run
go vet
but for some reason it didn't detect it. I even triedgo vet -loopclosure
, still not error shown :/
https://cs.opensource.google/go/x/tools/+/refs/tags/v0.1.7:go/analysis/passes/loopclosure/loopclosure.go;l=24;bpv=1 (thanks to gopher slack tools people).
Tests failed with an unrelated environment error:
|
yes, it's better to raise it as a blocker. |
This commit fixes the race condition introduced by f3d1010 that aimed to fix some race conditions. A test has its logging updated to use t.Log, so it only logs when verbosity is on and test line issuing the log is also shown. Some t.Helper() calls are also added.
634246f
to
1794e60
Compare
This commit fixes the race condition introduced by f3d1010 that aimed to fix some race conditions. A test has its logging updated to use t.Log, so it only logs when verbosity is on and test line issuing the log is also shown. Some t.Helper() calls are also added. (cherry picked from commit 2777272) # Conflicts: # libbeat/autodiscover/autodiscover_test.go
I can confirm this isn't in 8.3.2 so the bug was never released: https://github.com/elastic/beats/commits/v8.3.2 The original backport was merged here 2f69f86 |
This commit fixes the race condition introduced by f3d1010 that aimed to fix some race conditions. A test has its logging updated to use t.Log, so it only logs when verbosity is on and test line issuing the log is also shown. Some t.Helper() calls are also added. (cherry picked from commit 2777272) Co-authored-by: Tiago Queiroz <[email protected]>
…on (#32443) This commit fixes the race condition introduced by f3d1010 that aimed to fix some race conditions. A test has its logging updated to use t.Log, so it only logs when verbosity is on and test line issuing the log is also shown. Some t.Helper() calls are also added. (cherry picked from commit 2777272) Co-authored-by: Tiago Queiroz <[email protected]>
This commit fixes the race condition introduced by f3d1010 that aimed to fix some race conditions. A test has its logging updated to use t.Log, so it only logs when verbosity is on and test line issuing the log is also shown. Some t.Helper() calls are also added.
What does this PR do?
This commit fixes the race condition introduced by
f3d1010 that aimed to fix some race
conditions.
A test has its logging updated to use t.Log, so it only logs when
verbosity is on and test line issuing the log is also shown.
Some t.Helper() calls are also added.
Why is it important?
It fixes a bug
Checklist
- [x] I have made corresponding changes to the documentation- [x] I have made corresponding change to the default configuration files- [x] I have added tests that prove my fix is effective or that my feature worksCHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.## Author's ChecklistHow to test this PR locally
TestAutodiscoverWithMutlipleEntries
fromlibbeat/autodiscover/autodiscover_test.go
fails intermittently if the bug is not fixed. A set of 5 consecutive runs always triggered the bug for me. So to verify the fix, just run that test a few times:100 runs takes about 10s on my machine. All tests must pass.
Related issues
## Use cases## Screenshots## Logs