This (optional) setting will allow a user to opt-out of the middleware for certain URLs.

The setting is a list of strings, which are the paths of urls to ignore. The paths can be written with prefix '/' and/or suffix '/', or without them.

Related to issue #37

default_app_config is being removed in Django 4.1 and a new warning has shown up since django 3.2

https://docs.djangoproject.com/en/dev/internals/deprecation/#deprecation-removed-in-4-1

Describe the bug setup.py includes a dependency on CHANGELOG.rst which is not included in the .tar.gz packages

To Reproduce Retrieve django-guid-.tar.gz and try to run setup.py

I've tested this on 1.1.1, 2.0.0 2.1.0 & 2.20

Full stack trace [[email protected] django-guid-2.2.0]# /opt/acme/bin/python3 setup.py install Traceback (most recent call last): File "setup.py", line 7, in with open('CHANGELOG.rst') as changelog_file: FileNotFoundError: [Errno 2] No such file or directory: 'CHANGELOG.rst'

I am running a django application using gunicorn server, and there are some child threads that will be created by the parent thread. I am getting the guid (contextvar) using get_guid method in the parent thread, passing it as an argument to the child threads, and setting the guid contextvar in the child threads using set_guid method (both of these methods are present in django_guid.api module). Only then the guid is visible in the log messages.

Is this the best way to pass on the correlation-ids to child threads? Or is there an alternate better way?

I still need to:

• Bump version
• Write docs

but the core logic for this PR is done, and I think it would be good to review that before writing docs, to make sure you agree with the some of the design choices.

This PR introduces a new package setting, INTEGRATIONS which will be a list of pre-made integrations from the new integrations.py.

The idea for this PR originally, was only to add some functionality for integrating the correlation ID with Sentry, but I think it might be a good idea to design this feature in a way that opens up for more integrations in the future.

The second addition is the Sentry logic, which I've packaged in a class so that we can bundle validation logic and execution logic for each integration, and separate it from other code.

Also made some adjustments to doc-strings and inline comments here and there, but feel free to change them back

With ASGI being stable and more async support to Django is coming up, this package eventually have to change it's design to be ASGI compliant.

• ASGI by protocol can handle multiple requests on one thread. Every time await is used, the control of the loop will be handed back to the event loop, queuing the resumption of the function. The next function will run until it calls on an await, and then the entire thing repeats. This means that a thread will by design be able to handle multiple requests.

• Most of Django do not support awaitat the moment, so django-guid will work on ASGI today. The way it works right now is that when it gets an ASGI request on the event loop, it dispatches it to a thread pool where each thread again handles one request at the time.

Essentially this means that in the future, in order to keep this package living we have to find another ID to use. Luckily the Django people has been kind to us and implemented a replacement for us.

I will look into implementing this ASAP.

Thanks to knbk on #freenode.

I would like an easy way to override the Django error page views so that the request guid is included as part of the HTML. This is useful so that customers can easily send the guid to a support team to get faster help.

I have a few requests that I don't want to see in the logs

eg. a load balancer sends a "ping" once in a while to see the server is up the logs are spammed with generated new GUID messages:

django_guid - Header `Correlation-ID` was not found in the incoming request. Generated new GUID: cf306e6e90bc42238f025d8d3fddc8ac

for this request I would prefer to opt out of the middleware - a decorator would work nicely

@no_guid
def ping(request):
    return HttpResponse("Ok\n")

Edit: It turns out that to use a decorator for opt-out would require to use the process_view hook, which runs after all the middelwares __call__ methods have been run. If the GUID would only be added at that point, it wouldn't be useful for debugging of other middleware, which is not a good idea. For that reason, instead of a decorator, the plan is to use a "black list" of URLs to ignore. I edited the Issue title to reflect this change.

Bumps django from 3.2.10 to 3.2.11.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Changes

• Adds django matrix with supported package versions and python 3.9 to the test workflow 🚀
• Removes unnecessary isort config
• Updates package metadata to include python 3.9 and django 3.1

Celery tasks triggered by a request will not have the GUID (Correlation-ID) attached to it. Implement a solution to inject the GUID into the Celery logs.

For Celery tasks that are not triggered by a request, use the task-id instead as a GUID.

I really love the idea of small runnable examples. This sets up the starting point for that by adding

• examples/sync-views
• examples/async-views

My goal here has been to remove anything that isn't relevant to the very narrow functionality the examples are meant to show. The sync-views example now has a regular view and an ignored view, and we might actually go one step further and make a dedicated example out of the ignored view.

If you agree, we can do something like:

• examples/async-view
• examples/sync-view
• examples/ignore-url
• examples/celery-integration
• examples/sentry-integration
• examples/celery-and-sentry-integration

For now, I just wanted to open this as a first WIP proof of concept

Update: Added examples for the 6 things I consider important. We might be missing something though :slightly_smiling_face:

• [ ] Make ID generator and validator generic, implement transformer (mirror asgi-correlation-id)
• [ ] Split celery functionality into a separate package
• [ ] Split sentry functionality into a separate package
• [ ] Create extras for both
• [x] Update license
• [ ] Update test project to handle Django deprecation warnings
• [x] Update to Poetry v1.2
• [ ] Update classifiers
• [ ] Rework docs (drop sphinx and just have readmes per module?)
• [ ] Remove get_guid and set_guid
• [ ] Create example projects for each feature

Essentially we want to de-bloat the core a little, making it possible to install the core middleware without anything else. It's possible to install the middleware today, without adding celery as a dependency, but the celery code is still contained in the wheel.

There's also some Sentry + Celery logic to consider @JonasKs. Do we put that in its own third package? Something to think about 🤔