NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
PyPI · #997 most downloaded on PyPI
a little task queue
Last release 1 months ago
04 Sep 2026
Release timing varies
gaps range from 8 days to 7 months
Nearly every release is documented
notes for 59 of the last 60 stable releases
Nothing withdrawn
no release was ever pulled
15 years old
87 releases · first in 2012
Backwards-incompatible. The django stats app writes to its own sqlite database by default ( huey-stats.db in settings.BASE_DIR ), instead of DATABASES
Backwards-incompatible. The django stats app writes to its own sqlite database by default (huey-stats.db in settings.BASE_DIR), instead of DATABASES['default']. To keep recording in your main Django database, specify the database explicitly:
HUEY_STATS = {'database': 'postgresql://user:password@localhost/my_db'}HUEY_STATS['database'] takes a db-url or a peewee Database, or use
HUEY_STATS['filename'] to set the sqlite path. See the Django docs section
for building a peewee database from your existing DATABASES entry.
The admin Events log is now rendered from the stats database through
peewee, rather than being a ModelAdmin via ORM. It is now linked from the
dashboard's Recent events heading.
Consumer:
--shutdown-timeout option to bound graceful shutdown time.--graceful-signal option to allow making SIGTERM the graceful shutdown signal (e.g. -g TERM).User-facing APIs:
ttl to lock_task() and put_if_empty() so locks expire on their own. Supported by memory and redis storages, others raise NotImplementedError. RedisHuey requires server hash-field TTL support (redis 7.4+ or valkey 9+), RedisExpireHuey works on any version.timeout parameter to aget_result().Small stuff:
0-30/5) and wrap-around ranges (22-2, day_of_week='1-7'). Raise ValueError when a field matches no values.huey.Error and skipped (revoked, expired, cancelled) members as huey.SKIPPED instead of a raw exception or None.RedisExpireStorage.Result handles raise instead of blocking.id in TaskWrapper.s(), matching schedule().Storage:
Huey.pending() and Huey.scheduled(), logging the error, as read_schedule() already does.clean_name option to RedisHuey (default to True). Specify False to stop stripping non-alphanumeric characters from the storage namespace. The default will change in a future release.peek_data, pop_data and delete_data, and make RedisExpireStorage.incr() set the TTL atomically w/ the increment.SqliteStorage.dequeue() when the queue is empty, so idle consumers no longer block producers and the scheduler.SqliteStorage.read_schedule() delete to avoid sqlite's parameter limit when many tasks come due at once. Same fix in SqlHuey.SqliteStorage.read_schedule() and SqlHuey.read_schedule() by (timestamp, id), matching PostgresStorage.queue to the sqlite task index (task_queue_priority_id) so queues sharing a file no longer scan each other's rows. The old task_priority_id index is dropped when the schema is initialized. I'll get rid of the temporary in-band drop in a few releases.peek_many() to the storage API. Revocation checks now fetch the task and task-class keys in one round trip.result_items() on every storage backend. Redis and File storage previously returned bytes.Stats:
timeout, locked, rate-limited and retrying in stats recorder.max_events pruning to count rows per queue. With multiple queues sharing a stats db, each queue retained only a fraction of the configured cap.inflight_hours option to stats recorder, replacing the hardcoded 6 hour in-flight cutoff.change_hueydashboard permission for the django admin dashboard's revoke, restore and flush controls. Previously any staff user who could view the dashboard could also flush the queue.huey[stats] extra which installs ol' peewee.One column per quarter.
Use DoubleField for the stats ts , duration and started columns. On PG & MySQL the old FloatField was a 32-bit-shitter which lost a lot of seconds of
Use DoubleField for the stats ts, duration and started columns. On PG & MySQL the old FloatField was a 32-bit-shitter which lost a lot of seconds of precision. Existing PG/MySQL tables will need to run the SQL below to migrate OR just drop the tables and allow them to be rebuilt next run. SQLite was not affected. Fixes #909.
-- Postgres
alter table "huey_event" alter column "ts" type double precision;
alter table "huey_event" alter column "duration" type double precision;
alter table "huey_inflight" alter column "started" type double precision;
-- MySQL
alter table `huey_event` modify `ts` double not null;
alter table `huey_event` modify `duration` double;
alter table `huey_inflight` modify `started` double not null;Forward the Django database OPTIONS when setting up the stats recorder connection. Fixes / replaces #907 .
Flush buffered stats in the worker shutdown hook. Fixes issue where recycled workers might drop some writes.
FileLock fd per-thread. Under thread contention the shared fd was clobbered and released by the wrong thread, leaking a held flock and wedging every process using that storage path. FileHuey with the default thread workers deadlocked on first contention.FileLock fd per-thread. Under thread contention the shared fd
was clobbered and released by the wrong thread, leaking a held flock and
wedging every process using that storage path. FileHuey with the default
thread workers deadlocked on first contention.Ensure traceback is stored properly for error results.
os.register_at_fork. Previously the writer thread existed only in the process that called enable_stats(), so a consumer w/ worker_type='process' (or a preforking web server that loads the app before forking) buffered task events in its workers but never wrote them, and the dashboard showed tasks stuck on "enqueued".Remove the djhuey backend_class alias for huey_class (deprecated since 2.0) and the Django <1.2 settings.DATABASE_NAME queue-name fallback.
retry_backoff parameter to task() and periodic_task(). The first retry waits retry_delay seconds and each subsequent delay is multiplied by retry_backoff, giving exponentially-growing waits between retries.create_tables=False, which crashed SqliteHuey at connect and was silently ignored by the peewee SqlHuey. SqlStorage also gains initialize_schema() so the create_huey_tables command supports it.FileStorage by truncating to int. Previously they raised a TypeError.ResultTimeout from blocking Result.get() when the wait ends w/o an obtainable result, e.g. a dropped connection. Previously the internal EmptyData sentinel could be returned.retry_backoff when a task is rescheduled via Result.reschedule().RedisExpireHuey where destructive reads do not remove data.scheduled_items() that returned limit+1 items.SqlHuey counter methods, which run in the consumer via chords and rate limits.TaskLock.__enter__(), so with huey.lock_task('x') as lock: binds the lock instead of None.backend_class alias for huey_class (deprecated since 2.0) and the Django <1.2 settings.DATABASE_NAME queue-name fallback.CySqliteHuey, which drives the sqlite storage w/ cysqlite instead of the stdlib sqlite3 module and takes an open-ended pragmas dict in place of a fixed set of tuning parameters.Add a Django admin dashboard for task statistics. Adding huey.contrib.djhuey.stats to INSTALLED_APPS starts the huey.contrib.stats recorder in every p
huey.contrib.djhuey.stats to INSTALLED_APPS starts the huey.contrib.stats recorder in every process (incl. the consumer) and adds a Huey section to the admin: a dashboard w/ the same live stats and controls as the flask-peewee panel, plus a filterable event log. Stats are stored via peewee in the default Django database and require no migrations.Add store_intermediate_errors option (default true, preserving current behavior). When false, a task that fails with retries remaining no longer write
store_intermediate_errors option (default true, preserving current behavior). When false, a task that fails with retries remaining no longer writes its exception to the result store or runs its on_error handler until the retries are exhausted, so a blocking Result.get() waits for the final outcome instead of raising on the first failed attempt.create_tables option to the SQL storage backends (default true). Pass create_tables=False to skip the automatic create table if not exists at init, e.g. to manage huey's schema via Django migrations rather than have every web worker attempt DDL on import.create_huey_tables Django management command to create the tables when create_tables=False.on_error handlers accumulating one exception argument per failed attempt across retries. Handlers now receives only the current attempt's exception.huey.contrib.stats, a task-statistics engine: enable_stats(huey, db) records task signals into two peewee tables (huey_event, huey_inflight) and exposes a HueyStats query API for throughput, per-task timing, error-rates, in-flight and recent-event views. Depends only on peewee, so it can back a custom dashboard or exporter; enable it in the consumer to capture task execution.huey.contrib.flask_admin.HueyPanel, registered w/ admin.register_panel('Huey', HueyPanel, huey). It renders the recorded stats as a dashboard card plus a standalone page with live queue depths, throughput, per-task stats, running tasks and recent events. Has controls to revoke/restore tasks and flush the queue, schedule, results or locks. Requires flask-peewee 4.0.1+.Ensure we use a safe name for long postgres queue names. PG has a 63 byte limit on the channel name.
Add first-class Postgres support: PostgresHuey . Workers use LISTEN/NOTIFY when a task is enqueued, giving Redis-like dequeue latency without polling,
PostgresHuey. Workers use LISTEN/NOTIFY when a task is enqueued, giving Redis-like dequeue latency without polling, and dequeues use select ... for update skip locked so any number of consumers can share one database (requires psycopg 3.2+).django-tasks backport package, extending support to pre-6.0 Django.fork multiprocessing context for process workers, rather than setting the global start-method from the consumer entry-points. Fixes -k process on MacOS 3.8+ / Linux 3.14+ when the consumer is started via the huey_consumer console-script or a programmatic create_consumer().run().Add a Django 6.0 task backend - pretty much works the same way the normal Django integration works (manage.py run_huey), but using Django's canonical
Redis blocking dequeue no longer swallows ConnectionError -- the error propagates to the worker, which logs it and applies exponential backoff. Previo
ConnectionError -- the error propagates to the worker, which logs it and applies exponential backoff. Previously a downed redis server caused workers to busy-loop silently.None placeholder result. Previously the callback was silently lost.wait_result() when using notify_result with redis < 6 (or an unknown server version): timeouts over one second were cut to 1s, and sub-second timeouts blocked indefinitely.put_if_empty() is now atomic for the memory and file storage backends, restoring lock_task() mutual exclusion on those backends.FileLock no longer unlinks an existing lock file at construction time, which broke mutual exclusion for any process already holding the lock.signal.setitimer(), so float / sub-second timeouts work. Previously a timeout less than 1 second was silently ignored (alarm(0) cancels the timer) and fractional seconds were truncated.task is no longer dropped during serialization. Context tasks (context=True) inject the task instance into a copy of the kwargs rather than mutating the task's data.MemoryStorage.dequeue() and add_to_schedule() acquire the storage lock, like the other mutating methods.normalize_time() treats delay=0 as "now" rather than ignoring it, so e.g. expires=0 means "expires immediately" instead of "never expires".enqueued_items(limit) returned limit + 1 items from the producer end of the queue; it now returns the next-limit items to be dequeued, matching the other storage backends.<img width="821" height="616" alt="im-d573b49828" src="https://github.com/user-attachments/assets/0e85193f-625c-4fb4-a802-e2e6d4d15447" />
ConnectionError: the error
propagates to the worker, which logs it and applies exponential backoff.
Previously a downed redis server caused workers to busy-loop silently.None placeholder
result. Previously the callback was silently lost.wait_result() when using notify_result
with redis < 6 (or an unknown server version): timeouts over one second were
cut to 1s, and sub-second timeouts blocked indefinitely.put_if_empty() is now atomic for the memory and file storage backends,
restoring lock_task() mutual exclusion on those backends.FileLock no longer unlinks an existing lock file at construction time,
which broke mutual exclusion for any process already holding the lock.signal.setitimer(), so float / sub-second
timeouts work. Previously a timeout less than 1 second was silently ignored
(alarm(0) cancels the timer) and fractional seconds were truncated.task is no longer dropped during
serialization. Context tasks (context=True) inject the task instance into
a copy of the kwargs rather than mutating the task's data.MemoryStorage.dequeue() and add_to_schedule() acquire the storage lock,
like the other mutating methods.normalize_time() treats delay=0 as "now" rather than ignoring it, so
e.g. expires=0 means "expires immediately" instead of "never expires".enqueued_items(limit) returned limit + 1 items from the producer
end of the queue. It now returns the next-limit items to be dequeued,
matching the other storage backends.Fix bug in redis version parsing when using Elasticache or any other that sends major/minor. redis-py incorrectly parses these as floats because there
--max-tasks (previously was --max_tasks).!Three-Witches-oil-Banquo-Macbeth-Henry-Fuseli
chord() (map -> reduce) and group() (map) primitives.timeout (using SIGALRM for process and gevent.Timeout for greenlet) to control task running time. For threads, unfortunately, there's no good mechanism so instead APIs for cooperatively checking timeout are provided on the Task instance.rate_limit() for tasks.Result.is_ready() method for checking result readiness.notify_result=True when initializing your Huey instance.incr(key, amount=1) to storage API for atomic increment primitive. This is used by chord().wait_result() method to storage APIs for efficiently waiting for a result to become ready. The default implementation uses the exponential backoff from the previous implementation of a blocking Result.get() - so no changes are needed. However if you have a custom storage implementation, this provides a mechanism for pub/sub or other notification of result readiness.We have entered the brave new world of using pyproject.toml and github actions to shovel our ~shitty~ open-source software into our users docker conta
We have entered the brave new world of using pyproject.toml and github actions to shovel our ~shitty~ open-source software into our users docker containers and venvs and whatever other layers of abstraction I'm too geriatric to have heard about (no I will NOT put my hearing aids in). Welcome to the future, it is looking hellish. I had to beg the assistance of a chatbot trained on other shitty open-source projects to slap this together, nor do I understand what I was copying and pasting. Fellow travelers through the realms of ancient Night and Chaos, take comfort that at least the feeling is an old one.
Me miserable! Which way shall I fly Infinite wrath and infinite despair? Which way I fly is hell; myself am hell; And in the lowest deep a lower deep, Still threat'ning to devour me, opens wide, To which the hell I suffer seems a heaven.
Python(r), putting the snake oil in your build system.
* pypa/pypi is a joke. View commits !1733152230260308
Fix multiprocessing start method for python 3.14+.
This release adds the oft-requested SIGNAL_ENQUEUED. This signal, of necessity, runs in the calling process, since tasks are enqueued by the applicati
This release adds the oft-requested SIGNAL_ENQUEUED. This signal, of necessity, runs in the calling process, since tasks are enqueued by the application typically. The exception is tasks that are enqueued for retry by the consumer or tasks (including periodic tasks) enqueued by the scheduler. Use care when implementing this signal.
SIGNAL_ENQUEUED.FOR UPDATE SKIP LOCKED when supported by the database in the sql_huey storage engine.This release adds the oft-requested SIGNAL_ENQUEUED. This signal, of
necessity, runs in the calling process and not in the consumer, since tasks
are enqueued by the application typically. The exception is tasks that are
enqueued for retry by the consumer or tasks (including periodic tasks) enqueued
by the scheduler.
SIGNAL_ENQUEUED.FOR UPDATE SKIP LOCKED when supported by the database in the sql_huey
storage engine.Prevent bad task serialization in schedule from causing a batch of tasks to be lost, see #815..
More makework thanks to the ass-clowns running Python. Fix issue with deprecation of datetime.utcnow() in 3.12.
datetime.utcnow() in 3.12.TaskWrapper implementation, suitably named get_task_wrapper_class().revoke_all(), restore_all() and is_revoked() more robust for various input types.Python leadership:
Check to ensure the gevent monkeypatch was applied when running the consumer with greenlet workers, log warning if it is not.
delay=, eta= in Huey's .s() and .then() - this adds support for delaying or scheduling pipelines.preserve_pipeline=True).on_commit_task() decorator for Django extension that will enqueue the task after any database changes have been committed. This eliminates a common race condition where a task is enqueued and executed before the corresponding database changes have been committed.delay and eta when raising a RetryTask exception. This provides finer-grained control over when a task should be retried.ResultGroup.as_completed() helper to provide a way to deal with multiple results as they become available. Refs #746.asyncio helper for resolving task results asynchronously. Asyncio users can use await aget_result(result) or await aget_result_group(rg) to fetch a task result in non-blocking fashion.TaskLocked exception (#757).Improves propagation of errors in task results and includes fix for newer versions of pip.
Improves propagation of errors in task results and includes fix for newer versions of pip.
Add is_locked(lock_name) to test whether lock is held.
is_locked(lock_name) to test whether lock is held.CancelExecution within a Task, and override retries.periodic_task() wrapper for MiniHuey class.Fix compatibility with redis-py 4.0.0+.
Fix implementation of schedule-pop Lua script so it works with Redis cluster.
db_task() and db_periodic_task().Attempt to reconnect to database if connection becomes unusable (e.g. due to a server restart). See: huey.contrib.sql_huey.SqlHuey.
huey.contrib.sql_huey.SqlHuey.FileStorage - use fcntl.flock() instead.Task expiration: https://huey.readthedocs.io/en/latest/guide.html#task-expiration
crontab() parsing strict, raising an error if an invalid interval specification is given. You probably want to enable this.Add hook (Huey.build_error_result) for customizing the error result metadata.
Huey.build_error_result) for customizing the error result metadata.Add SIGNAL_INTERRUPTED to signal when a task is interrupted when a consumer exits abruptly.
SIGNAL_INTERRUPTED to signal when a task is interrupted when a consumer exits abruptly.Huey.create_consumer() API within the Django management command, to allow Django users to customize the creation of the Consumer instance.Use monotonic clock for timing operations within the consumer.
on_shutdown handler to djhuey namespace.Adds task-id into metadata for task exceptions (refs #461).
repr (refs #460).call_local method of Django helper extension db_periodic_task().FileHuey and full FileStorage implementation.shutdown() hook, which will be run in the context of the worker threads/processes during shutdown. This hook can be used to clean-up shared or global resources, for example.Fix semantics of SIGNAL_COMPLETE so that it is not sent until the result is ready.
SIGNAL_COMPLETE so that it is not sent until the result is ready.RedisHuey) so that it is easier to subclass / extend. Previously we just used a partial application of the constructor, which could be confusing.Allow AsyncResult object used in MiniHuey to support the __call__() method to block and resolve the task result.
AsyncResult object used in MiniHuey to support the __call__() method to block and resolve the task result.run_huey management command, the huey loggers will not be configured if another logging handler is already registered to the huey namespace.kyoto tycoon <http://fallabs.com/kyototycoon>_ which supports task priority and the option to do automatic result expiration. Requires the ukt <https://github.com/coleifer/ukt>_ python package and a custom kyototycoon lua script.SqliteHuey.Ensure that task()-decorated functions retain their docstrings.
task()-decorated functions retain their docstrings.huey namespace, rather than the root logger.result, signal and disconnect_signal in the Django huey extension.SignedSerializer, which signs and validates task messages.SqliteStorage so that it can be more easily extended to support other databases.Added new contrib module sql_huey, which uses peewee _ to provide storage layer using any of the supported databases (sqlite, mysql or postgresql).
sql_huey, which uses peewee <https://github.com/coleifer/peewee>_ to provide storage layer using any of the supported databases (sqlite, mysql or postgresql).RedisExpireHuey, which modifies the usual Redis result storage logic to use an expire time for task result values. A consequence of this is that this storage implementation must keep all result keys at the top-level Redis keyspace. There are some small changes to the storage APIs as well, but will only possibly affect maintainers of alternative storage layers.PriorityRedisExpireHuey which combines the priority-queue support from PriorityRedisHuey with the result-store expiration mechanism of RedisExpireHuey.Huey to use zlib as the compression method instead of gzip.FileStorageMethods storage mixin, which uses the filesystem for task result-store APIs (put, peek, pop).Huey implementations (e.g. RedisHuey) are no longer subclasses, but instead are partial applications of the Huey constructor.sql_huey, which uses peewee <https://github.com/coleifer/peewee>_
to provide storage layer using any of the supported databases (sqlite, mysql
or postgresql).RedisExpireHuey, which modifies the usual Redis result storage logic
to use an expire time for task result values. A consequence of this is that
this storage implementation must keep all result keys at the top-level Redis
keyspace. There are some small changes to the storage APIs as well, but will
only possibly affect maintainers of alternative storage layers.PriorityRedisExpireHuey which combines the priority-queue
support from PriorityRedisHuey with the result-store expiration mechanism
of RedisExpireHuey.Huey to use zlib as the compression method instead of gzip.FileStorageMethods storage mixin, which uses the filesystem for task
result-store APIs (put, peek, pop).Huey implementations (e.g. RedisHuey) are no longer
subclasses, but instead are partial applications of the Huey constructor.This section describes the changes in the 2.0.0 release. A detailed list of changes can be found here: https://huey.readthedocs.io/en/latest/changes.html
Overview of changes:
always_eager mode has been renamed to immediate mode. Unlike previous
versions, immediate mode involves the same code paths used by the consumer
process. This makes it easier to test features like task revocation and task
scheduling without needing to run a dedicated consumer process. Immediate
mode uses an in-memory storage layer by default, but can be configured to use
"live" storage like Redis or Sqlite.Serializer abstraction allows users to customize the serialization
format used when reading and writing tasks.on_error handler, in addition to the
previously-supported on_complete handler.ResultGroup object which simplifies reading
the results of a sequence of task executions.SqliteHuey has been promoted out of contrib, onto an equal footing with
RedisHuey. To simplify deployment, the dependency on
peewee was removed and the Sqlite
storage engine uses the Python sqlite3 driver directly.Small fixes, fixed typo in Exception class being caught by scheduler.
This section describes the changes in the 2.0.0 release. A detailed list of changes can be found here: https://huey.readthedocs.io/en/latest/changes.h
This section describes the changes in the 2.0.0 release. A detailed list of changes can be found here: https://huey.readthedocs.io/en/latest/changes.html
Overview of changes:
always_eager mode has been renamed to immediate mode. Unlike previous
versions, immediate mode involves the same code paths used by the consumer
process. This makes it easier to test features like task revocation and task
scheduling without needing to run a dedicated consumer process. Immediate
mode uses an in-memory storage layer by default, but can be configured to use
"live" storage like Redis or Sqlite.Serializer abstraction allows users to customize the serialization
format used when reading and writing tasks.on_error handler, in addition to the
previously-supported on_complete handler.ResultGroup object which simplifies reading
the results of a sequence of task executions.SqliteHuey has been promoted out of contrib, onto an equal footing with
RedisHuey. To simplify deployment, the dependency on
peewee was removed and the Sqlite
storage engine uses the Python sqlite3 driver directly.Previously, it was possible for certain tasks to be silently ignored if a task with that name already existed in the registry. To fix this, I have mad
Backwards-incompatible changes
Previously, it was possible for certain tasks to be silently ignored if a task with that name already existed in the registry. To fix this, I have made two changes:
Together, these changes are intended to fix problems described in #386.
Because these changes will impact the serialization (and deserialization) of messages, it is important that you consume all tasks (including scheduled tasks) before upgrading.
Always-eager mode changes
In order to provide a more consistent API, tasks enqueued using always_eager mode will now return a dummy TaskResultWrapper implementation that wraps the return value of the task. This change is designed to provide the same API for reading task result values, regardless of whether you are using always-eager mode or not.
Previously, tasks executed with always_eager would return the Python value directly from the task. When using Huey with the consumer, though, task results are not available immediately, so a special wrapper TaskResultWrapper is returned, which provides helper methods for retrieving the return value of the task. Going forward, always_eager tasks will return EagerTaskResultWrapper, which implements the same get() API that is typically used to retrieve task return values.
Backwards-incompatible changes
Previously, it was possible for certain tasks to be silently ignored if a task with that name already existed in the registry. To fix this, I have made two changes:
Together, these changes are intended to fix problems described in #386.
Because these changes will impact the serialization (and deserialization) of messages, it is important that you consume all tasks (including scheduled tasks) before upgrading.
Always-eager mode changes
In order to provide a more consistent API, tasks enqueued using always_eager
mode will now return a dummy TaskResultWrapper implementation that wraps the
return value of the task. This change is designed to provide the same API for
reading task result values, regardless of whether you are using always-eager
mode or not.
Previously, tasks executed with always_eager would return the Python value
directly from the task. When using Huey with the consumer, though, task results
are not available immediately, so a special wrapper TaskResultWrapper is
returned, which provides helper methods for retrieving the return value of the
task. Going forward, always_eager tasks will return EagerTaskResultWrapper,
which implements the same get() API that is typically used to retrieve task
return values.
simpledb APIs have
changed and no longer use this method.Compatibility with redis-py 3.0, updated requirements / dependencies.
Log time taken to execute tasks at default log level.
Fixed regression where in *always eager* mode exceptions within tasks were being swallowed instead of raised.
More granular "extras" installation options.
Remove call to SimpleDB Client.connect(), as the simpledb APIs have changed and no longer use this method.
simpledb APIs have changed and no longer use this method.Ensure that the default SIGINT handler is registered. This fixes an edge-case that arises when the consumer is run without job control, which causes i
TaskResultWrapper.reset() to enable resetting the results of tasks that
failed and are subsequently being retried.Ensure the scheduler loop does not drift (fixes #304).
TaskResultWrapper.reset() to enable resetting the results of tasks that failed and are subsequently being retried.Due to problems with the django patch that added support for multiple huey instances, I've decided to rollback those changes.
Due to problems with the django patch that added support for multiple huey instances, I've decided to rollback those changes.
Django integration in Huey 1.9.0 will work the same as it had previously in 1.7.x and earlier.
Apologies, I should have reviewed the patch more thoroughly and insisted on better test coverage.
In 1.8.0, support for multiple huey instances was added (with thanks to @Sebubu and @MarcoGlauser for the patches). Although existing Django/Huey apps
In 1.8.0, support for multiple huey instances was added (with thanks to @Sebubu and @MarcoGlauser for the patches). Although existing Django/Huey apps should continue to work, there is a new configuration format available and I'd recommend that you take a look at the docs and switch over to it:
NOTE: These changes were remove in 1.9.0
In 1.8.0, support for multiple huey instances was added (with thanks to @Sebubu and @MarcoGlauser for the patches). Although existing Django/Huey apps should continue to work, there is a new configuration format available and I'd recommend that you take a look at the docs and switch over to it:
Previous versions of huey would store the traceback and associated metadata for a failed task within the result_store, regardless of whether store_err
Previous versions of huey would store the traceback and associated metadata for
a failed task within the result_store, regardless of whether store_errors
was true or not. As of 1.7.0, task exceptions will only be stored in the result
store if store_errors is True. See #290 for discussion.
Previous versions of huey would store the traceback and associated metadata for
a failed task within the result_store, regardless of whether store_errors
was true or not. As of 1.7.0, task exceptions will only be stored in the result
store if store_errors is True. See #290 for discussion.
Add backwards-compatibility to queue serialization protocol so that 1.6 consumers can continue to work with tasks enqueued by huey versions 1.5 and lo
Support for task pipelining and task function partials
RetryTask exception.TaskException being raised.task() and periodic_task() decorators, which should have the added benefit of making them easier to extend.RetryTask exception.TaskException being raised.task() and periodic_task() decorators, which should have the added benefit of making them easier to extend.In v1.6.0, the serialization format of tasks has changed to accomodate an extra piece of metadata. As a result, tasks enqueued with huey versions previous to 1.6 will not be able to be consumed by the 1.6 consumer.
At present there is a workaround available in 1.6.1, but it will be removed when 1.7.0 is released later.
task() decorators.contrib.minimal task scheduler timing.TaskLock and Huey.lock_task() helpers.Huey API to add method for creating the consumer.Added support for specifying a retry and retry_delay on periodic tasks.
Simply pass the desired values into the periodic_task() decorator after the
validation function, as keyword arguments.
Allow arbitrary settings to be specified in task() decorators.
task() decorators.contrib.minimal task scheduler timing.Implemented pre-execute and post-execute hooks.
Implemented atomic "set if not exists" for Redis and SQLite, which is used by the locking APIs.
Includes addition of TaskLock and Huey.lock_task() helpers.
TaskLock and Huey.lock_task() helpers.Huey API to add method for creating the consumer.Added support for gracefully restarting the consumer using SIGHUP.
Added support for specifying a retry and retry_delay on periodic tasks. Simply pass the desired values into the periodic_task() decorator after the va
Added support for specifying a retry and retry_delay on periodic tasks.
Simply pass the desired values into the periodic_task() decorator after the
validation function, as keyword arguments.
Allow all instances of a task to be revoked/restored by adding the revoke(), restore() and is_revoked() methods to all decorated tasks (where previous
revoke(), restore() and is_revoked() methods to all decorated tasks
(where previously they were only available on periodic tasks).gevent worker model.BaseStorage APIs.Thanks to @mindojo-victor and @nachtmaar for help with some of the above items.
revoke(), restore() and is_revoked() methods to all decorated tasks
(where previously they were only available on periodic tasks).gevent worker model.BaseStorage APIs.Thanks to @mindojo-victor and @nachtmaar for help with some of the above items.
7 to represent Sunday when doing day-of-week calculations
in the crontab helper.Add "minihuey", an in-process task scheduler using gevent.
7 to represent Sunday when doing day-of-week calculations
in the crontab helper.Fixed a subtle bug in the way Huey calculated when to run the periodic task scheduler. If you had configured the consumer to check the schedule at an
Fixed a subtle bug in the way Huey calculated when to run the periodic task scheduler. If you had configured the consumer to check the schedule at an interval that was not a factor of 60, then there is a chance that periodic tasks may be scheduled at incorrect intervals from one minute to the next. This is fixed in 1.4.0.
Added better signal handling in order to support graceful shutdown. Graceful
shutdown involves letting workers finish executing any tasks they may be
processing at the time the shutdown signal is received. The default behavior is
to interrupt the workers mid-task. Huey uses SIGTERM to shutdown the
consumer immediately, and SIGINT to gracefully shutdown.
Added support for using either a global task registry, or a registry bound to
a particular Huey instance. The default behavior is to use a global registry
(backwards-compatible). To bind the registry to a single Huey instance, pass
global_registry=False when initializing your Huey object.
Added a reschedule() method to the TaskResultWrapper.
Documentation clean-ups and additions, particularly around the logic used to handle datetime conversion. Also added docs on shutdown modes for huey consumer.
Fixed a subtle bug in the way Huey calculated when to run the periodic task scheduler. If you had configured the consumer to check the schedule at an interval that was not a factor of 60, then there is a chance that periodic tasks may be scheduled at incorrect intervals from one minute to the next. This is fixed in 1.4.0.
Added better signal handling in order to support graceful shutdown. Graceful
shutdown involves letting workers finish executing any tasks they may be
processing at the time the shutdown signal is received. The default behavior is
to interrupt the workers mid-task. Huey uses SIGTERM to shutdown the
consumer immediately, and SIGINT to gracefully shutdown.
Added support for using either a global task registry, or a registry bound to
a particular Huey instance. The default behavior is to use a global registry
(backwards-compatible). To bind the registry to a single Huey instance, pass
global_registry=False when initializing your Huey object.
Added a reschedule() method to the TaskResultWrapper.
Documentation clean-ups and additions, particularly around the logic used to handle datetime conversion. Also added docs on shutdown modes for huey consumer.
Smarter conversion between datetimes, so that huey will correctly interpret naive or timezone-aware datetimes and properly convert to UTC when configured to do so. Previously, huey only operated on naive datetimes. Many thanks to @Antoine for this patch-set.
Documentation clean-ups and additions.
Smarter conversion between datetimes, so that huey will correctly interpret naive or timezone-aware datetimes and properly convert to UTC when configu
Smarter conversion between datetimes, so that huey will correctly interpret naive or timezone-aware datetimes and properly convert to UTC when configured to do so. Previously, huey only operated on naive datetimes. Many thanks to @Antoine for this patch-set.
Documentation clean-ups and additions.
Your coding agent can read these notes before it upgrades. Set up the MCP server →