Description

I had a need to dictate how the span creation would happen, specifically because the span I wanted to be the root was at the gunicorn worker level, not Django nor WSGI. Main reason was to include its request log in the trace.

Also, in our context, one span is enough to wrap gunicorn, WSGI and _DjangoMiddleware (for billing and practical purposes), so had WSGI and _DjangoMiddleware contribute with their attributes to the span created by gunicorn.

I had to override the entirety of _DjangoMiddleware.process_request in order to reuse the existing span and to avoid end_on_exit that's currently hardcoded to true.

This _DjangoMiddleware._get_span will allow achieving this behavior without such wide override.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

• Tests at instrumentation/opentelemetry-instrumentation-django/tests/test_middleware.py

Does This PR Require a Core Repo Change?

• Yes. - Link to PR:
• No.

Checklist:

See contributing.md for styleguide, changelog guidelines, and more.

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated