Celery worker_process_init and solo concurrency (Fix)

The Fix

pip install celery==4.4.0rc5

Based on closed celery/celery issue #5405 · PR/commit linked

Production note: Most teams hit this during upgrades or environment changes. Roll out with a canary and smoke critical endpoints (health, OpenAPI/docs) before 100%.

Jump to Verify Open PR/Commit

@@ -4,6 +4,8 @@
 import os
 
+from celery import signals
+
 from .base import BasePool, apply_target

repro.py

@signals.worker_init.connect
def celery_worker_init(sender, **kwargs):
    if sender.pool_cls == "solo": 
        celery_worker_process_init(sender=None, **kwargs)

verify

Re-run the minimal reproduction on your broken version, then apply the fix and re-run.

fix.md

Option A — Upgrade to fixed release\npip install celery==4.4.0rc5\nWhen NOT to use: This fix should not be used if uniform signal behavior is not required across different worker pools.\n\nOption C — Workaround\nis:\nWhen NOT to use: This fix should not be used if uniform signal behavior is not required across different worker pools.\n\n

Why This Fix Works in Production

Trigger: this is solved, but the shutdown signal is still not being sent. Either I did not notice before or it's a regression.
Mechanism: The worker_process_init signal was not emitted for solo concurrency, causing inconsistent behavior
Why the fix works: Implemented signal emission during the initialization of solo worker as described in issue #5405. (first fixed release: 4.4.0rc5).

Production impact:

If left unfixed, the same config can fail only in production (env differences), causing startup failures or partial feature outages.

Why This Breaks in Prod

The worker_process_init signal was not emitted for solo concurrency, causing inconsistent behavior
Production symptom (often without a traceback): this is solved, but the shutdown signal is still not being sent. Either I did not notice before or it's a regression.

Proof / Evidence

GitHub issue: #5405
Fix PR: https://github.com/celery/celery/pull/5562
First fixed release: 4.4.0rc5
Reproduced locally: No (not executed)
Last verified: 2026-02-09
Confidence: 0.85
Did this fix it?: Yes (upstream fix exists)
Own content ratio: 0.75

Discussion

High-signal excerpts from the issue thread (symptoms, repros, edge-cases).

Jump to Sources Open on GitHub

“if you dont mind, could you please try celery 4.3rc3?”

@auvipy · 2019-03-21 · source

“@thedrow I expect uniform behavior of signals between pools. Even when not spawning a proper subprocess, the "solo" process is still a worker process that…”

@neg3ntropy · 2019-04-11 · source

“@neg3ntropy what issue are you facing? which version you are using?”

@auvipy · 2020-05-05 · source

“this is solved, but the shutdown signal is still not being sent. Either I did not notice before or it's a regression.”

@neg3ntropy · 2020-05-06 · source

Failure Signature (Search String)

this is solved, but the shutdown signal is still not being sent. Either I did not notice before or it's a regression.

Copy-friendly signature

signature.txt

Failure Signature
-----------------
this is solved, but the shutdown signal is still not being sent. Either I did not notice before or it's a regression.

Error Message

Signature-only (no traceback captured)

error.txt

Error Message
-------------
this is solved, but the shutdown signal is still not being sent. Either I did not notice before or it's a regression.

Minimal Reproduction

repro.py

@signals.worker_init.connect
def celery_worker_init(sender, **kwargs):
    if sender.pool_cls == "solo": 
        celery_worker_process_init(sender=None, **kwargs)

What Broke

Inconsistent signal behavior led to confusion and bugs during debugging with solo concurrency.

Why It Broke

The worker_process_init signal was not emitted for solo concurrency, causing inconsistent behavior

Fix Options (Details)

Option A — Upgrade to fixed release Safe default (recommended)

pip install celery==4.4.0rc5

When NOT to use: This fix should not be used if uniform signal behavior is not required across different worker pools.

Use when you can deploy the upstream fix. It is usually lower-risk than long-lived workarounds.

Option C — Workaround Temporary workaround

is:

When NOT to use: This fix should not be used if uniform signal behavior is not required across different worker pools.

Use only if you cannot change versions today. Treat this as a stopgap and remove once upgraded.

Fix reference: https://github.com/celery/celery/pull/5562

First fixed release: 4.4.0rc5

Last verified: 2026-02-09. Validate in your environment.

When NOT to Use This Fix

This fix should not be used if uniform signal behavior is not required across different worker pools.

Verify Fix

verify

Re-run the minimal reproduction on your broken version, then apply the fix and re-run.

Did This Fix Work in Your Case?

Quick signal helps us prioritize which fixes to verify and improve.

Prevention

Capture the exact failing error string in logs and tests so you can reproduce via a minimal script.
Pin production dependencies and upgrade only with a reproducible test that hits the failing path.

Version Compatibility Table

Version	Status
4.4.0rc5	Fixed

Related Issues

No related fixes found.

Cluster: celery:configuration-error Celery hub Celery best practices All hubs All clusters

Related clusters: Data consistency Duplicates Duplicate processing

Sources

We don’t republish the full GitHub discussion text. Use the links above for context.