Weblate and Redis: Task Queue Consistency During Failed Upgrades

Answer to the question

During an upgrade, if the database rolls back but Redis still holds tasks created by the newer code, Weblate does not automatically reconcile or purge those stale tasks. The only documented mechanism is to manually clear the queue with Celery’s purge command or by deleting Redis keys directly. There is no built‑in Weblate API that validates a task’s signature against the current migration state before a worker attempts to execute it; any mismatch will surface as a runtime exception on the worker side.

Typical recovery workflow

1. Verify the database is at the intended migration state:

   python manage.py showmigrations --plan
   

2. Clear pending Celery tasks that belong to Weblate:

   # If Redis is dedicated to Weblate
   celery -A weblate purge
   
   # If Redis is shared, target the specific queue
   celery -A weblate purge -Q weblate
   

3. Restart the Celery workers so they begin consuming from a clean queue.
4. Monitor worker logs for any "Task not registered" or "Invalid task signature" errors to confirm the stale tasks are gone.

What you need to check next

Does the Redis instance used by Weblate also serve other services? If so, a blanket purge will delete tasks for those services as well. Specify the queue name in the command or manually delete only the keys matching the Weblate queue pattern.

Explanation of behavior

Weblate relies on Celery for asynchronous work. Celery stores task payloads in Redis as opaque blobs keyed by celery-task-*. When a migration rollback happens, the database schema reverts but Redis is unaffected. Celery workers will still pick up the queued tasks and attempt to import the corresponding task functions. If the function name or its arguments no longer match the restored schema, the worker raises an exception but does not automatically remove the task from the queue. Consequently, the only documented way to avoid running incompatible tasks is to purge the queue manually after ensuring the database is in the correct state.

No automatic validation mechanism

There is no Weblate‑specific hook that checks a task’s payload against the current migration state before execution. Task design (e.g., idempotent logic, versioned task names) and operator discipline are the only safeguards.

Practical verification steps

• List pending tasks before purge:

  redis-cli --scan --pattern 'celery-task-*'
  

• Run the purge command and confirm the reported count matches the number of tasks listed.
• After workers restart, watch logs for any signature‑related errors.