GeoNode relies on Celery for several asynchronous processes. Currently:

• RabbitMQ is used as the message broker
• django-celery-results is used as the results backend

During complex harvesting workflows (involving exceptions handled by the harvesting logic), we observed that Celery sometimes lost track of its state, eventually raising errors like:

[2025-07-29 10:26:12,173: WARNING/MainProcess] Can't find ChordCounter for Group b8914b46-8ca9-4bc2-8423-de660471bb9b 

From our investigation, the root cause is the django-celery-results backend (CELERY_RESULT_BACKEND = "django-db"). This backend is fragile and not well-suited for advanced task orchestration patterns (e.g., chords, groups of chords, chains).

We experimented with replacing django-celery-results with Redis (as the Celery results backend only). In these tests, the harvesting workflows became significantly more robust and reliable.

Furthermore, Redis can also act as the message broker, replacing RabbitMQ.

Proposal

We propose migrating from the current setup (RabbitMQ + django-celery-results) to a single backend: Redis.
While RabbitMQ itself works fine, consolidating on Redis will simplify maintenance, improve reliability, and reduce complexity by removing the need to manage two separate tools.