Instead of checking if the django-q logger has any handlers directly,
use the hasHandlers [1] method, which will check if any parent loggers
have handlers as well.
This fixes a bug where django-q configures it's own logging even though
the root logger has a handler set
1. https://docs.python.org/3/library/logging.html#logging.Logger.hasHandlers
Co-authored-by: Wesley Ellis <wellis@benchsci.com>
* feat: option to save tasks per group/func/name
* test: update tests for save limit
* fix: convert func when save-limit checking
when passed as function it needs to be converted to work
* Add warning if option is not valid
Co-authored-by: Noortheen Raja <jnoortheen@gmail.com>
* Add the group column to OrmQ admin page
* Add group field to tasks list and search_field
* Add search by name to Schedule admin page
* Limit succesful task history per schedule with SAVE_LIMIT_GROUP config
* Improve ScheduleAdmin list view performance
Co-authored-by: Marc Sabatier <marc@sabatier.online>
* Black linting
* Adding Black to dev dependencies and upping minimal python to 3.6.2 for compatibility
* Updating packages
* Removing pip-tools input and exporting requirements with poetry
* Deleting old setup files and test runner
* Trying 1.3.7
* Looser extras requirements to prevent conflicts
* Sorted imports with isort
* Added iSort to dev dependencies
* Fixes localtime for naive setups
* Add a warning for misconfiguration.
As specified in the docs, by default the settings result in a configuration where slow tasks that run for more than 60s cause repeated running of tasks, which has caused a few issues. This warning doesn't change the defaults, which would be a marge larger change, but instead provides a, hopefully, helpful message to the user.
* fixed missing bracket
* Update conf.py
fixed spelling
* Update conf.py
Made bool work for python 3.6+
* Fixing typo
Co-authored-by: Ilan Steemers <koed00@gmail.com>
If a task fails with an exception, it is retried until it
succeeds. This is contrary to what is said in the documentation: under
the "Architecture" section, heading "Broker" it says that even when a
task errors, it's still considered a successful delivery. Failed tasks
never get acknowledged however, thereby being retried after the
timeout period. See also issues #238 and #194.
This patch adds an option to acknowledge failures, thereby closing
issue #238. Issue #194 would require some more work. The default of
this option is set to `False`, thereby maintaining backwards
compatibility.
