Using the Celery result backend as the primary task state store

Wed, 14 Oct 2026 07:58:09 +0900

When an application hands long-running jobs to Celery workers, it’s tempting to keep a copy of each task’s state in the application’s own documents and update it as the task progresses. That copy can easily drift from what Celery itself knows. An alternative is to make Celery’s result backend, here the celery_taskmeta collection in MongoDB, the single source of truth for tasks, with application documents keeping at most a task ID. This article goes through what that takes in practice, both on the API side and in the workers.

Forwarding Celery task events to Socket.IO in a FastAPI app

Tue, 13 Oct 2026 22:58:04 +0900

In a FastAPI app that hands long-running jobs, such as training a model, to Celery workers, clients usually want to know how their task is doing: when it starts, how far along it is, and when it succeeds or fails. One way to do this is to build a feedback system of one’s own, with a dedicated queue in RabbitMQ that workers publish to and the API consumes. Celery already has such a mechanism, though: task events, which workers send through the broker and which anyone connected to it can receive. This article shows how to emit custom progress events from a task and forward all task events to clients with Socket.IO.

Celery on Maxime Moreillon

Using the Celery result backend as the primary task state store

Forwarding Celery task events to Socket.IO in a FastAPI app