Celery Once is a Python library that prevents multiple execution and queuing of Celery tasks, ensuring a task runs only once. It's particularly useful for idempotent operations or tasks that should not be duplicated. The current version is 3.0.1, and it maintains an active release cadence with significant changes often introduced in major versions.
pip install celery-onceVerified import paths — ran on the pinned version, not inferred.
This quickstart demonstrates how to integrate `celery-once` with a Celery task using the `QueueOnce` base class. It configures the Redis backend for `celery-once` and defines a task that will only execute once globally. Remember to start a Redis server and a Celery worker to see it in action.
If upgrading and using the file backend, any pending locks from prior versions will be ignored. No direct migration is possible; existing locks effectively become stale. Redis backend is unaffected.
It is highly recommended to remove any previous `celery-once` lock keys from Redis when upgrading from 1.x.x to 2.x.x to prevent unexpected behavior. Consult GitHub issues like #67 for more context.
Upgrade `celery-once` to version 2.1.1 or newer. If you must use an older version, ensure tasks using the `File` backend are short-lived or manage file descriptors carefully (though upgrading is strongly preferred).
Always explicitly define the `CELERY_ONCE` dictionary in your Celery application's configuration (`app.conf.update` or `celeryconfig.py`), specifying the `backend` and `default_timeout`.
Upgrade `celery-once` to version 3.0.0 or newer. This version introduces hashing and truncation for file backend keys, resolving the filename length issue.
Upgrade `celery-once` to version 2.1.1 or newer. This version includes a fix to ensure file descriptors are correctly closed after use.
Upgrade `celery-once` to version 2.0.0 or newer. This version refactors the Redis backend to use a robust SETNX-based RedLock mechanism, which effectively mitigates race conditions. Remember to clear old Redis keys when upgrading.
Ensure your task code handles exceptions gracefully. If a lock is genuinely stuck, you may need to manually clear the lock key from your chosen backend (e.g., delete the specific key from Redis or the file from the filesystem path configured for `celery-once`). Consider using a shorter `default_timeout` for locks if tasks are generally short-lived.