This issue illustrates a potential issues that may affect Django adapter users.
Django's ORM establishes a database connection per thread. For the threads managed by Django (which are supposed to be used for directly handing web requests), Django ORM cleans the established connections up under the hood once the processing on the thread completes (= request_finished signal).
On the other hand, in the case where Django ORM models are used in an unmanaged thread, Django does not handle the cleanup of the connections bound to the thread although the Django framework automatically associates a new connection to the thread. This half-heartedly maintained resource possibly may cause stale DB connection related issues.
To learn more details of this Django behavior, checking the following ticket is helpful for understanding this:
https://code.djangoproject.com/ticket/9878
As Bolt for Python utilizes threads for enabling developers to run ack() method asynchronously (as long as process_before_response=False, which is the default), this framework should have a special treatment for this possible issue with Django.
As the solution for this issue (and possible similar needs), we'll introduce a new completion callback to the ListenerRunner mechanism. The handler will be quite similar to the ListenerErrorHandler callback but the given callback function is executed in the finally clause of listener runner invocation:
https://github.com/slackapi/bolt-python/blob/v1.4.4/slack_bolt/listener/thread_runner.py#L99-L126
Also, for this Django specific issue, we'll add a custom lazy listener runner to the Django adapter module.
I've already implemented the initial version of this. We can discuss its details in my upcoming pull request.
This issue illustrates a potential issues that may affect Django adapter users.
Django's ORM establishes a database connection per thread. For the threads managed by Django (which are supposed to be used for directly handing web requests), Django ORM cleans the established connections up under the hood once the processing on the thread completes (= request_finished signal).
On the other hand, in the case where Django ORM models are used in an unmanaged thread, Django does not handle the cleanup of the connections bound to the thread although the Django framework automatically associates a new connection to the thread. This half-heartedly maintained resource possibly may cause stale DB connection related issues.
To learn more details of this Django behavior, checking the following ticket is helpful for understanding this:
https://code.djangoproject.com/ticket/9878
As Bolt for Python utilizes threads for enabling developers to run
ack()method asynchronously (as long asprocess_before_response=False, which is the default), this framework should have a special treatment for this possible issue with Django.As the solution for this issue (and possible similar needs), we'll introduce a new completion callback to the
ListenerRunnermechanism. The handler will be quite similar to theListenerErrorHandlercallback but the given callback function is executed in thefinallyclause of listener runner invocation:https://github.com/slackapi/bolt-python/blob/v1.4.4/slack_bolt/listener/thread_runner.py#L99-L126
Also, for this Django specific issue, we'll add a custom lazy listener runner to the Django adapter module.
I've already implemented the initial version of this. We can discuss its details in my upcoming pull request.