-
Notifications
You must be signed in to change notification settings - Fork 34
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
Backwards incompatible change in 4.1.0 #183
Comments
It is something that Could you explain what you are doing so I could refactor accordingly? Your change does not allow Async support, I'd like an elegant solution that will allow everything to work. |
We're adding extra logging variables. In our case:
|
Have you considered using the signal? |
@gvangool, like you suggested I added a note in https://django-structlog.readthedocs.io/en/latest/changelog.html#february-4th-2023 In your case, I have the feeling you can do like the example from the documentation: from django.dispatch import receiver
from django_structlog import signals
import structlog
@receiver(signals.bind_extra_request_metadata)
def bind_awesome_stuff(request, logger, **kwargs):
# Add your code using the request
# url_name: the resolved URL name
# func: the view function (as an import path)
# project_id: a URL kwarg that is available on 50% of our views
structlog.contextvars.bind_contextvars(
url_name="?",
func="?",
project_id="?",
) |
I rolled back the changes in 4.1.1. you can switch back to
|
We have a custom
RequestMiddleware
that is inheriting fromdjango_structlog.middlewares.RequestMiddleware
, with the introduction of async support in #180 that became a function instead of a class.At that point, tests started to fail with a
TypeError
.If anyone else runs into it, you can make the following change.
Can we flag the 4.1.0 release as having backwards-incompatible changes?
The text was updated successfully, but these errors were encountered: