Celery Scheduler and Worker Reliability Fixes Worth Reviewing

Celery is a distributed task queue used in data pipelines and background processing systems. Its latest activity adds explicit Celery Beat task provenance while correcting scheduler ordering, green pool capacity, Redis result consumption, retry state, and credential masking.

Beat tasks now carry their origin

The clearest new behavior is a celery_beat_task message header on tasks sent by Celery Beat. The task provenance commit copies the schedule entry options, creates a headers mapping when one is absent, and sets the marker to True before dispatch. Existing headers remain present.

This is a small addition with useful operational consequences. A worker, tracing hook, or message inspection tool can identify scheduled traffic without inferring origin from task names or queue layout. That makes it easier to separate periodic pipeline work from application driven jobs in logs and metrics. The implementation in celery/beat.py applies the marker to both registered task dispatch and the fallback path that sends by task name.

There is one detail to note. The marker is authoritative: an existing celery_beat_task header is set to True. Consumers should treat it as scheduler metadata, not as a caller controlled value. The associated test_beat.py coverage checks both header creation and preservation of unrelated existing headers.

Beat also received a scheduling correction. The retry heap fix repositions entries that ask to retry later. A deferred entry needs a fresh place in the heap; retaining its previous position risks stale ordering as the scheduler selects the next due task.

Green pool autoscaling gets a capacity correction

Celery fixed capacity handling for autoscaling workers that use Eventlet or Gevent. The green pool autoscale commit touches both celery/concurrency/eventlet.py and celery/concurrency/gevent.py, with unit coverage for each pool.

Capacity bookkeeping is part of the control loop that decides whether a worker can accept more jobs or should grow. An error there can make configured autoscale limits disagree with actual green thread capacity. For operators running bursty extraction jobs, the practical check is simple: watch claimed concurrency, active task count, and queue depth together after upgrading.

The activity summary provides no throughput or latency benchmark, so this should be read as a correctness fix rather than a performance claim. It is most relevant to deployments using the green pools with autoscaling. Prefork workers do not appear in the changed file set for this fix.

Redis cleanup and retry state become less surprising

Two fixes target state that outlives the operation that created it. The Redis result consumer change removes a redundant unsubscribe in celery/backends/redis.py. Result consumers already have delicate subscription life cycles, so avoiding duplicate cleanup reduces needless commands and makes shutdown behavior easier to reason about.

Separately, the automatic retry fix prevents mutation of shared retry_kwargs. Shared mutable configuration is a classic worker footgun. One invocation can otherwise affect how a later invocation retries, especially in a long lived process handling many instances of the same task.

Timeout handling also gained an effective traceback clearing fix. Tracebacks retain references to stack frames and their local values. Clearing them on a timeout path matters for workers that process repeated failures over long runs, even though the supplied activity does not quantify memory impact.

Inspection output and logs are safer to operate

Worker inspection no longer exposes credentials inside alternate connection values. The credential masking change covers alternates returned by inspect statistics. Teams that collect this output into support bundles, monitoring systems, or job logs should still control access, but the default output now has a safer boundary.

Logging received a smaller usability improvement. The formatter date change adds datefmt support to ColorFormatter and TaskFormatter. The changes span celery/app/log.py, celery/utils/log.py, defaults, documentation, and tests. Consistent timestamp rendering helps when Celery logs feed the same pipeline as broker, database, and scheduler logs.

Finally, deprecations for task_sent and Result moved to the Celery 6.0 timeline. That timeline adjustment offers more migration time, but it does not cancel the migration. Inventory those uses while the compatibility window remains open.

What to watch

First, verify that any custom message header filtering accepts the new Beat marker and does not reserve the same key for another meaning. Second, compare queue depth with reported capacity on Eventlet and Gevent workers after rollout. Third, scan stored inspect output created before the credential masking fix, since safer future output does not remove secrets from old logs or support archives.