opentelemetry-instrumentation-starlette: remove starlette version ceiling #3529
Conversation
| @@ -239,7 +239,7 @@ def instrument_app( | |||
| meter_provider, | |||
| schema_url="https://opentelemetry.io/schemas/1.11.0", | |||
| ) | |||
| if not getattr(app, "is_instrumented_by_opentelemetry", False): | |||
| if not getattr(app, "_is_instrumented_by_opentelemetry", False): | |||
There was a problem hiding this comment.
This needs to match the setting at https://github.com/open-telemetry/opentelemetry-python-contrib/pull/3529/files#diff-a4901479b7a21ad4f5d45a7f3e47b2ada3f9d8ae4ae7f9e68c2001e8b8067611L330
I think the problem becomes double telemetry, but presumably no one uses such an old version of starlette to allow the auto-instrumentation to kick in to trigger it.
| @@ -331,9 +332,6 @@ def __init__(self, *args: Any, **kwargs: Any): | |||
| # adding apps to set for uninstrumenting | |||
| _InstrumentedStarlette._instrumented_starlette_apps.add(self) | |||
|
|
|||
| def __del__(self): | |||
| _InstrumentedStarlette._instrumented_starlette_apps.remove(self) | |||
There was a problem hiding this comment.
This would fail if the app isn't in the set, which would happen in the .clear() call in StarletteInstrumentation.uninstrument(). And actually, __del__ could only ever be called after such a call because the set held a strong reference, preventing __del__ from being called. I am guessing older versions of starlette had a similar memory leak that was fixed, causing the newer ones to trigger the crash here.
I changed to WeakSet which should fix it, and we don't need __del__ since it's automatically cleaned when the object goes away
| def setUp(self) -> None: | ||
| patcher = patch.dict( |
There was a problem hiding this comment.
Previously patch was decorating setUp - it was active only for the duration of setUp, not the entire test case. Recent starlette seems to initialize middleware lazily so the patch needs to be active during the test case for it. I switched to this pattern that activates it both for setUp (for older eager starlette) and the test cases (for newer lazy starlette). Note, moving the decorator to the class level would loose the former.
anuraaga
changed the title
|
@anuraaga this is ready to review since you fixed the testcase right? |
| @@ -230,7 +230,8 @@ def test_basic_post_request_metric_success(self): | |||
| dict(point.attributes), expected_duration_attributes | |||
| ) | |||
| if metric.name == "http.server.duration": | |||
| self.assertAlmostEqual(duration, point.sum, delta=30) | |||
There was a problem hiding this comment.
latest had trouble with this assertion because it initializes middleware lazily, so the duration ends up being way longer than the actual request's duration. I think in principal, it's only safe to check the request duration is not larger than the test duration rather than comparing the actual values so I changed the assertions.
I wanted to use self.assertGreater(point.sum, 0) but the old ms metric is rounded and easily 0 on a fastish machine - not sure if the rounding is actually required for it but that would be a change in the ASGI middleware
Yup should be ok now |
|
Oh no, I didn't check existing PRs before making this one and now see @MattiasDC's #3456 is quite similar. I found the tests seem to pass fine for the current baseline version so didn't raise it here which is the main difference. Feel free to reject this PR as a duplicate and get that one in instead though, then I can send another one with just the |
There was a problem hiding this comment.
Funny that running the same command, I got different result for this file 😅
There was a problem hiding this comment.
Yeah to get it to update, I removed the file first and ran the command
Description
Removes the starlette version ceiling which is currently set to a very ancient version of starlette. I think this is fairly sane to do since the instrumentation only uses starlette's public API (
add_middleware) and should be relatively stable.There was test failure when bumping but it was an issue with the test code itself, not the instrumentation, so I fixed it.
Fixes #3317
/cc @xrmx
Type of change
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Does This PR Require a Core Repo Change?
Checklist:
See contributing.md for styleguide, changelog guidelines, and more.