The Fix
pip install celery==5.6.0
Based on closed celery/celery issue #9909 · PR/commit linked
Production note: This usually shows up under retries/timeouts. Treat it as a side-effect risk until you can verify behavior with a canary + real traffic.
@@ -1741,7 +1741,7 @@ def _prepared(self, tasks, partial_args, group_id, root_id, app,
def _apply_tasks(self, tasks, producer=None, app=None, p=None,
add_to_parent=None, chord=None,
- args=None, kwargs=None, **options):
+ args=None, kwargs=None, group_index=None, **options):
"""Run all the tasks in the group.
from celery import group, shared_task
@shared_task
def add(x, y):
return x + y
@shared_task(bind=True)
def group_replace(self):
self.replace(group([add.s(1 ,1), add.s(2, 2)]))
print(group_replace.apply_async().get()) # <- should be [2, 4], sometimes is [4, 2]
Re-run the minimal reproduction on your broken version, then apply the fix and re-run.
Option A — Upgrade to fixed release\npip install celery==5.6.0\nWhen NOT to use: This fix should not be used if the task replacement behavior is intended to maintain the original group order.\n\n
Why This Fix Works in Production
- Trigger: - [x] I have included all related issues and possible duplicate issues
- Mechanism: The group_index value passed to _apply_tasks overrides the expected ordering of tasks in a group
- Why the fix works: Preserves group ordering when replacing a task with a group by preventing the passing of a `group_index` in the options. (first fixed release: 5.6.0).
- If left unfixed, this can cause silent data inconsistencies that propagate (bad cache entries, incorrect downstream decisions).
Why This Breaks in Prod
- The group_index value passed to _apply_tasks overrides the expected ordering of tasks in a group
- Production symptom (often without a traceback): - [x] I have included all related issues and possible duplicate issues
Proof / Evidence
- GitHub issue: #9909
- Fix PR: https://github.com/celery/celery/pull/9910
- First fixed release: 5.6.0
- Reproduced locally: No (not executed)
- Last verified: 2026-02-08
- Confidence: 0.85
- Did this fix it?: Yes (upstream fix exists)
- Own content ratio: 0.59
Discussion
High-signal excerpts from the issue thread (symptoms, repros, edge-cases).
“I reproduced this issue locally (in my case group tasks replacing with a group, with redis backend)”
“I identified the issue to be here https://github.com/celery/celery/blob/70087e49888cefe092ac2068ceb37769d8e8dd4b/celery/canvas.py#L1793”
Failure Signature (Search String)
- - [x] I have included all related issues and possible duplicate issues
- or possible duplicates to this issue as requested by the checklist above.
Copy-friendly signature
Failure Signature
-----------------
- [x] I have included all related issues and possible duplicate issues
or possible duplicates to this issue as requested by the checklist above.
Error Message
Signature-only (no traceback captured)
Error Message
-------------
- [x] I have included all related issues and possible duplicate issues
or possible duplicates to this issue as requested by the checklist above.
Minimal Reproduction
from celery import group, shared_task
@shared_task
def add(x, y):
return x + y
@shared_task(bind=True)
def group_replace(self):
self.replace(group([add.s(1 ,1), add.s(2, 2)]))
print(group_replace.apply_async().get()) # <- should be [2, 4], sometimes is [4, 2]
What Broke
Tasks in a group return results in random order instead of the expected sequence.
Why It Broke
The group_index value passed to _apply_tasks overrides the expected ordering of tasks in a group
Fix Options (Details)
Option A — Upgrade to fixed release Safe default (recommended)
pip install celery==5.6.0
Use when you can deploy the upstream fix. It is usually lower-risk than long-lived workarounds.
Fix reference: https://github.com/celery/celery/pull/9910
First fixed release: 5.6.0
Last verified: 2026-02-08. Validate in your environment.
When NOT to Use This Fix
- This fix should not be used if the task replacement behavior is intended to maintain the original group order.
Verify Fix
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 |
|---|---|
| 5.6.0 | Fixed |
Related Issues
No related fixes found.
Sources
We don’t republish the full GitHub discussion text. Use the links above for context.