-
Notifications
You must be signed in to change notification settings - Fork 527
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
add config reload debouncer #8439
Conversation
prevent multiple reloads in rapid succession.
This pull request does not have a backport label. Could you fix it @stuartnelson3? 🙏
NOTE: |
💔 Tests Failed
Expand to view the summary
Build stats
Test stats 🧪
Test errorsExpand to view the tests failures
|
Provide some context as to how the debouncer is working within the code.
🌐 Coverage report
|
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.
Did this fix the issues seen in Cloud? If so, why, and can we add a test to cover whatever the problem was? The reload stuff is already complicated, I'm wary of making it even more so.
start the debounce() method on the first call to trigger(), using an internal buffered channel to indicate that fn is currently being debounced.
// Update the internal state to show we're currently debouncing | ||
// fn execution and start the debounce method. | ||
go func() { | ||
d.debounce(ctx) |
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.
Don't we need to send the result of debounce back to res? Otherwise the error won't be propagated and line 308 will never happen either.
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 believe that, when we send res
on line 308, that will be added to the slice of channels that will have the error sent to them. I think this is being verified in the test.
However, maybe the code would be more readable if we send on this channel, and move d.triggerc <- res
under default
?
After building apm-server locally and packaging that into an elastic-agent container which is then run on cloud, it appears that the issue isn't related to the actual code within the apm-server, but potentially something around the compilation in CI. The locally built apm-server binary did not have the same bug as is seen with the BC created by CI, so this fix is likely unnecessary. Potentially in the future it might be nice to reduce the number of reloads if both an update to the config and the output config appear in rapid succession. |
prevent multiple reloads in rapid succession.
to be tested in cloud, an attempt at seeing if this fixes the bug setting the output registry (#8383)
how to test