oteltest: make CheckReceivers environment more similar to the collector #43302
+86
−55
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The CheckReceivers function is designed to start receivers in the same process to assert conditions. This simulated environment should closely resemble the real OTel collector startup. This PR fixes some inconsistencies in the test environment. First, when instantiating receivers, the collector first creates them using the factory and only then starts each component. Previously, we were creating and starting each receiver sequentially, which is incorrect and masked issues with global state when multiple receivers were present. Second, a Beats receiver logger inherits from the zap.Core of the collector logger. This core includes certain fields—specifically data_type, kind, and name. In the tests, these fields were previously missing, so this PR ensures they are included.
mauri870
added
cleanup
Team:Elastic-Agent-Data-Plane
botelastic
bot
added
needs_team
|
This pull request does not have a backport label.
To fixup this pull request, you need to add the backport labels for the needed
|
|
Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane) |
mauri870
force-pushed
the
oteltest-fix-logger-fields
branch
from
9222265 to
bacd8b8
Compare
khushijain21
approved these changes
Mar 17, 2025
mauri870
added
backport-8.x
leehinman
approved these changes
Mar 17, 2025
mergify bot
pushed a commit
that referenced
this pull request
Mar 17, 2025
…or (#43302) * oteltest: make CheckReceivers environment more similar to the collector The CheckReceivers function is designed to start receivers in the same process to assert conditions. This simulated environment should closely resemble the real OTel collector startup. This PR fixes some inconsistencies in the test environment. First, when instantiating receivers, the collector first creates them using the factory and only then starts each component. Previously, we were creating and starting each receiver sequentially, which is incorrect and masked issues with global state when multiple receivers were present. Second, a Beats receiver logger inherits from the zap.Core of the collector logger. This core includes certain fields—specifically data_type, kind, and name. In the tests, these fields were previously missing, so this PR ensures they are included. * remove i++ * use EventuallyWithT for assertions * fix imports * specify factory per receiver (cherry picked from commit 8d31036)
6 tasks
mergify bot
pushed a commit
that referenced
this pull request
Mar 17, 2025
…or (#43302) * oteltest: make CheckReceivers environment more similar to the collector The CheckReceivers function is designed to start receivers in the same process to assert conditions. This simulated environment should closely resemble the real OTel collector startup. This PR fixes some inconsistencies in the test environment. First, when instantiating receivers, the collector first creates them using the factory and only then starts each component. Previously, we were creating and starting each receiver sequentially, which is incorrect and masked issues with global state when multiple receivers were present. Second, a Beats receiver logger inherits from the zap.Core of the collector logger. This core includes certain fields—specifically data_type, kind, and name. In the tests, these fields were previously missing, so this PR ensures they are included. * remove i++ * use EventuallyWithT for assertions * fix imports * specify factory per receiver (cherry picked from commit 8d31036)
6 tasks
mauri870
added a commit
that referenced
this pull request
Mar 18, 2025
…or (#43302) (#43319) * oteltest: make CheckReceivers environment more similar to the collector The CheckReceivers function is designed to start receivers in the same process to assert conditions. This simulated environment should closely resemble the real OTel collector startup. This PR fixes some inconsistencies in the test environment. First, when instantiating receivers, the collector first creates them using the factory and only then starts each component. Previously, we were creating and starting each receiver sequentially, which is incorrect and masked issues with global state when multiple receivers were present. Second, a Beats receiver logger inherits from the zap.Core of the collector logger. This core includes certain fields—specifically data_type, kind, and name. In the tests, these fields were previously missing, so this PR ensures they are included. * remove i++ * use EventuallyWithT for assertions * fix imports * specify factory per receiver (cherry picked from commit 8d31036) Co-authored-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
mauri870
added a commit
that referenced
this pull request
Mar 18, 2025
…or (#43302) (#43318) * oteltest: make CheckReceivers environment more similar to the collector The CheckReceivers function is designed to start receivers in the same process to assert conditions. This simulated environment should closely resemble the real OTel collector startup. This PR fixes some inconsistencies in the test environment. First, when instantiating receivers, the collector first creates them using the factory and only then starts each component. Previously, we were creating and starting each receiver sequentially, which is incorrect and masked issues with global state when multiple receivers were present. Second, a Beats receiver logger inherits from the zap.Core of the collector logger. This core includes certain fields—specifically data_type, kind, and name. In the tests, these fields were previously missing, so this PR ensures they are included. * remove i++ * use EventuallyWithT for assertions * fix imports * specify factory per receiver (cherry picked from commit 8d31036) Co-authored-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The CheckReceivers function is designed to start receivers in the same process to assert conditions. This simulated environment should closely resemble the real OTel collector startup.
This PR fixes some inconsistencies in the test environment.
First, when instantiating receivers, the collector first creates them using the factory and only then starts each component. Previously, we were creating and starting each receiver sequentially, which is incorrect and masked issues with global state when multiple receivers were present.
Second, a Beats receiver logger inherits from the zap.Core of the collector logger. This core includes certain fields—specifically data_type, kind, and name. In the tests, these fields were previously missing, so this PR ensures they are included.
Last but not least, replace Eventually with EventuallyWithT so we aggregate assertions properly.
Proposed commit message
Checklist
CHANGELOG.next.asciidocorCHANGELOG-developer.next.asciidoc.Related issues