Weblate and Redis: Task Queue Consistency During Failed Upgrades

Question

Weblate utilizes Celery and Redis to manage asynchronous translation tasks. During a version upgrade, the system executes Django migrations to update the PostgreSQL schema and updates the application logic to handle new task signatures.

A critical boundary exists between the persistent database state and the volatile task queue in Redis. If an upgrade fails mid-process, the database may be rolled back to a previous snapshot, but the Redis queue may still contain serialized tasks generated by the newer, failed version of the application. This creates a mismatch where the restarted service attempts to execute tasks using a schema or API version that no longer exists in the restored database.

What is the documented behavior for purging or reconciling stale Celery tasks in Redis after a failed Weblate upgrade? Is there a mechanism to validate task compatibility against the current database migration state before execution?

Weblate and Redis: Task Queue Consistency During Failed Upgrades

Weblate utilizes Celery and Redis to manage asynchronous translation tasks. During a version upgrade, the system executes Django migrations to update the PostgreSQL schema and updates the application logic to handle new task signatures.

0 answers

Your perspective belongs here.

0 question comments