-
Notifications
You must be signed in to change notification settings - Fork 778
Fix FastAPI issue with APIRoute subclasses #3681
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
base: main
Are you sure you want to change the base?
Conversation
090e9c1
to
de946d3
Compare
Fixes: open-telemetry#3671 When an APIRoute subclass would overwrite the matches method with an implementation that depended on non-standard fields existing on the HTTP connection scope, this would cause a failure when the OpenTelemetryMiddleware tried to get the default span details for the incoming request. This has been fixed by using the matches implementation on the Route class for any subclass of Route. This should be sufficient since the only information we are trying to get from that method is the path for the request.
This commit adds tests that illustrate the original issue that was being experienced for custom api route implementations when they depended on non-standard fields existing on the ASGI HTTP connection scope. Before the fix was implemented, the inclusion of a custom API route in the FastAPI application would cause an exception to be raised inside the OpenTelemetryMiddleware since the non-standard fields do not exist on the ASGI HTTP connection scope until after the subsequent middleware runs and adds the expected fields.
299f2de
to
8878698
Compare
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.
Needs CI fix and asserts in the test
custom API routers that depend on non-standard fields on the ASGI scope. | ||
""" | ||
resp = self._client.get("/custom-router/success") | ||
self.assertEqual(resp.status_code, 200) |
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.
Can you assert spans and it's attributes as well?
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 added some asserts for spans and it's attributes.
match, _ = starlette_route.matches(scope) | ||
match, _ = ( | ||
Route.matches(starlette_route, scope) | ||
if isinstance(starlette_route, Route) |
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.
This will be true for almost everything no? Maybe check if type(starlette_route).matches is Route.matches
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.
It's been a while since I wrote this so I forget why I did this specifically. I would have thought that your suggestion would work but when I made that change and ran the test suite, it appears that that change makes several tests fail.
374130c
to
fcca86c
Compare
Description
When an APIRoute subclass would overwrite the matches method with an implementation that depended on non-standard fields existing on the HTTP connection scope, this would cause a failure when the OpenTelemetryMiddleware tried to get the default span details for the incoming request. This has been fixed by using the matches implementation on the Route class for any subclass of Route. This should be sufficient since the only information we are trying to get from that method is the path for the request.
Fixes #3671
Type of change
Please delete options that are not relevant.
How Has This Been Tested?
This has been validated with automated tests that are included in this pull request.
Does This PR Require a Core Repo Change?
Checklist:
See contributing.md for styleguide, changelog guidelines, and more.