Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Worker executes task after rejecting it when ETA timestamp conversion fails

Closed Beginner friendly
#10,875 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
82/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
backend

Research direction

The issue identifies celery/worker/strategy.py and the ETA conversion exception path. Read that path first and trace what happens after req.reject(requeue=False). Add a regression test for an ETA conversion failure, then confirm the rejected request is not reserved or executed.

Written by the indexing model from the issue text.

Description

Issue Type: Bug Report

Checklist

Mandatory Debugging Information

  • I have included the output of celery -A proj report in the issue.
    (if you are not able to do this, then at least specify the Celery
    version affected).
  • I have verified that the issue exists against the main branch of Celery.
  • I have included the contents of pip freeze in the issue.
  • I have included all the versions of all the external dependencies required
    to reproduce this bug.

Optional Debugging Information

  • I have tried reproducing the issue on more than one Python version
    and/or implementation.
  • I have tried reproducing the issue on more than one message broker and/or
    result backend.
  • I have tried reproducing the issue on more than one version of the message
    broker and/or result backend.
  • I have tried reproducing the issue on more than one operating system.
  • I have tried reproducing the issue on more than one workers pool.
  • I have tried reproducing the issue with autoscaling, retries,
    ETA/Countdown & rate limits disabled.
  • I have tried reproducing the issue after downgrading
    and/or upgrading Celery and its dependencies.

Related Issues and Possible Duplicates

Related Issues
  • None found.
Possible Duplicates
  • None found.

Environment & Settings

Celery version: 5.7.0b1

celery report Output:

software -> celery:5.7.0b1 (collider) kombu:5.7.0b1 py:3.13.15
            billiard:4.3.1 py-amqp:5.4.1
platform -> system:Windows arch:64bit, WindowsPE
            kernel version:11 imp:CPython
loader   -> celery.loaders.default.Loader
settings -> transport:amqp results:disabled

deprecated_settings: None

The issue was reproduced against the current main branch corresponding to
Celery 5.7.0b1.

Steps to Reproduce

Required Dependencies

  • Python: 3.13.15
  • Celery: 5.7.0b1 / current main
  • Kombu: 5.7.0b1
  • Billiard: 4.3.1
  • py-amqp: 5.4.1
  • OS: Windows 11, 64-bit
  • Broker: The behavior can be reproduced with an in-process memory:// broker; the celery report above shows the development environment's default AMQP transport.
  • Result backend: Not required
Python Packages

The relevant dependency versions from celery report are:

celery==5.7.0b1
kombu==5.7.0b1
billiard==4.3.1
py-amqp==5.4.1
Python 3.13.15

A complete pip freeze can be added separately if required.

Other Dependencies

No external result backend is required.

The issue is in the worker's ETA handling in
celery/worker/strategy.py.

A memory:// broker is sufficient to reproduce the control-flow issue.

Minimally Reproducible Test Case

The problematic code path is:

try:
    eta = to_timestamp(to_system_tz(req.eta))
except (OverflowError, ValueError) as exc:
    error(...)
    req.reject(requeue=False)

There is no return after req.reject(requeue=False).

When ETA conversion raises OverflowError or ValueError, execution therefore
continues into the normal task-processing path:

task_reserved(req)
handle(req)

For example, with the worker timezone set to Asia/Kolkata, an ETA such as:

9999-12-31T23:59:59+00:00

can raise OverflowError during timezone conversion/timestamp conversion.

The observed behavior is:

Couldn't convert ETA ...
Request.reject(requeue=False)
task_reserved(req)
handle(req)

The task is consequently executed immediately even though its message has
already been rejected.

Expected Behavior

When ETA conversion fails with OverflowError or ValueError, the worker
should reject the message and stop processing that request.

After:

req.reject(requeue=False)

the worker should not reserve or execute the task.

Actual Behavior

The worker rejects the message but then continues processing the same request.

As a result, the task can execute immediately despite having just been rejected
with requeue=False.

The problematic control flow is:

except (OverflowError, ValueError) as exc:
    error(...)
    req.reject(requeue=False)

# execution incorrectly continues
task_reserved(req)
handle(req)

The minimal fix is to return immediately after rejecting the request:

 except (OverflowError, ValueError) as exc:
     error(...)
     req.reject(requeue=False)
+    return

I reproduced the issue against the current main branch. The regression tests
fail on the original implementation and pass with this control-flow fix.

Dominant language
Python
Stars
29k
Forks
5.2k
Avg merge
1d 19h
Merged PRs (30d)
125

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from celery/celery

All issues in celery/celery

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.