Rework FastAPI integration using a global dependency

[sentrivana]

Instead of patching a private function, use a global Dependency that has access to the Request object instead.

Additionally, move setting the thread ID and name span attributes to the Starlette integration.

[linear-code]

PY-2896

[faizansaiyed123]

I’d like to take this on as a community contribution. I traced the current FastAPI path: patch_get_request_handler() monkey-patches FastAPI’s request handler, and the sync dependant wrapper currently handles thread ID/name span metadata. My understanding is that this should move to a global FastAPI dependency that receives the Request, while the thread metadata moves into the Starlette integration so the behavior is shared at the ASGI integration layer. I’ll trace the request lifecycle and existing tests first, then add regression coverage before changing behavior. Please confirm that matches the intended direction, and whether the dependency should be attached at the application level or another specific point.

[sentrivana]

Hey @faizansaiyed123, thanks for your interest. You're welcome to give it a try. Some pointers:

• The dependency should be a global dependency, so I believe we need to attach it at the application level. Or do we have other options there?
• Please check whether the dependency approach works for all FastAPI versions we support; I'm not sure if dependencies were always part of FastAPI.
• Please create two pull requests, one for the thread metadata, and one for the dependency.

What kind of regression tests would you add? Ideally, the existing test suite still working would be the signal that the migration was successful.

I'll assign the issue to you.