Skip to content

Conversation

zacharycmontoya
Copy link
Contributor

Motivation

We're in the process of enhancing the container-id extraction support in the C++ tracer and I wanted to update the testing to support it. The current logic depends on the weblog applications implementing a /read_file endpoint and the test runner trusts this endpoint, only making assertions if that value is present. This means we're showing false positives against the C++ tracer code. I'm proposing changes to make the test runner get the expected value itself, instead of getting both the expected value and the actual value from the weblog application.

Changes

Refactors the container-id weblog test logic to get the expected value by directly running cat /proc/self/cgroup on the weblog container, instead of depending on the weblog HTTP server to self-report the cgroup via the /read_file endpoint.

This PR also removes all /read_file endpoints since this was the only use of the endpoint.

Workflow

  1. ⚠️ Create your PR as draft ⚠️
  2. Work on you PR until the CI passes
  3. Mark it as ready for review
    • Test logic is modified? -> Get a review from RFC owner.
    • Framework is modified, or non obvious usage of it -> get a review from R&P team

🚀 Once your PR is reviewed and the CI green, you can merge it!

🛟 #apm-shared-testing 🛟

Reviewer checklist

  • If PR title starts with [<language>], double-check that only <language> is impacted by the change
  • No system-tests internal is modified. Otherwise, I have the approval from R&P team
  • A docker base image is modified?
    • the relevant build-XXX-image label is present
  • A scenario is added (or removed)?

…y call 'cat /proc/self/cgroup' on the weblog container instead of asking the weblog application (over an HTTP call) to read a file. This allows us to instead call the '/' endpoint which all weblog applications should be handling.
…essary. They were only used for the container-id testing.
@zacharycmontoya zacharycmontoya marked this pull request as ready for review July 17, 2025 20:39
@zacharycmontoya zacharycmontoya requested review from a team as code owners July 17, 2025 20:39
@zacharycmontoya zacharycmontoya requested review from P403n1x87, quinna-h, jade-guiton-dd, ygree, smola and sezen-datadog and removed request for a team July 17, 2025 20:39
reason="Missing endpoint",
)
@missing_feature(context.library == "ruby" and context.weblog_variant != "rails70", reason="Missing endpoint")
self.r = weblog.get("/")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason for keeping this request ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I kept it because I thought it would be necessary in order to test that trace payloads sent to the agent have the required header. What happens if I remove it?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your test code is checking all traces trigerred by the scenario, not only this one (it's the default scenario , and there are thousand of them).

Well, it does not hurt, but as your test is no linked to only this requests, it's not that necessary. Up to you, both are fine to me.

Copy link
Collaborator

@cbeauchesne cbeauchesne left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a small non-blocking comment/question

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants