internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: celery/celery

Issue:
Redis connection timeouts are not coerced correctly
Found using celery 4.1.0.

## Steps to reproduce

Configure with redis as a backend with timeouts set in the url:

```
result_backend = 'redis://127.0.0.1:6379?socket_timeout=30&socket_connect_timeout=5'
```

## Expected behavior

Timeouts are applied and celery works normally.

## Actual behavior

Errors are raised by the socket library that the timeout needs to be a float.

Pull request incoming.


Discussion:

Resolving patch:
diff --git a/celery/backends/redis.py b/celery/backends/redis.py
--- a/celery/backends/redis.py
+++ b/celery/backends/redis.py
@@ -29,6 +29,7 @@
 
 try:
     import redis
+    import redis.connection
     from kombu.transport.redis import get_redis_error_classes
 except ImportError:  # pragma: no cover
     redis = None  # noqa
@@ -249,6 +250,12 @@ def _params_from_url(self, url, defaults):
         db = db.strip('/') if isinstance(db, string_t) else db
         connparams['db'] = int(db)
 
+        for key, value in query.items():
+            if key in redis.connection.URL_QUERY_ARGUMENT_PARSERS:
+                query[key] = redis.connection.URL_QUERY_ARGUMENT_PARSERS[key](
+                    value
+                )
+
         # Query parameters override other parameters
         connparams.update(query)
         return connparams


Test patch:
diff --git a/t/unit/backends/test_redis.py b/t/unit/backends/test_redis.py
--- a/t/unit/backends/test_redis.py
+++ b/t/unit/backends/test_redis.py
@@ -234,6 +234,20 @@ def test_url(self):
         assert x.connparams['socket_timeout'] == 30.0
         assert x.connparams['socket_connect_timeout'] == 100.0
 
+    def test_timeouts_in_url_coerced(self):
+        x = self.Backend(
+            ('redis://:bosco@vandelay.com:123//1?'
+             'socket_timeout=30&socket_connect_timeout=100'),
+            app=self.app,
+        )
+        assert x.connparams
+        assert x.connparams['host'] == 'vandelay.com'
+        assert x.connparams['db'] == 1
+        assert x.connparams['port'] == 123
+        assert x.connparams['password'] == 'bosco'
+        assert x.connparams['socket_timeout'] == 30
+        assert x.connparams['socket_connect_timeout'] == 100
+
     def test_socket_url(self):
         self.app.conf.redis_socket_timeout = 30.0
         self.app.conf.redis_socket_connect_timeout = 100.0
Repository: celery/celery

Issue:
The celery document has a mistake about crontab
## about crontab
the document in this link about crontab simple.
http://docs.celeryproject.org/en/master/userguide/periodic-tasks.html

**crontab(0, 0, day_of_month='2-30/3')**
Execute on every even numbered day.

shuld be 
**crontab(0, 0, day_of_month='2-30/2')**


Discussion:
plz send a fix

Resolving patch:
diff --git a/celery/schedules.py b/celery/schedules.py
--- a/celery/schedules.py
+++ b/celery/schedules.py
@@ -361,7 +361,7 @@ class crontab(BaseSchedule):
         - A (list of) integers from 1-31 that represents the days of the
           month that execution should occur.
         - A string representing a Crontab pattern.  This may get pretty
-          advanced, such as ``day_of_month='2-30/3'`` (for every even
+          advanced, such as ``day_of_month='2-30/2'`` (for every even
           numbered day) or ``day_of_month='1-7,15-21'`` (for the first and
           third weeks of the month).
 


Test patch:
Repository: celery/celery

Issue:
celery beat: OSError: [WinError 87]
Suddenly I started getting this error when I run celery beat

```
celery beat -A proj 
```

Funny thing is that celery worker still runs but beat doesn't.
I'm running version 4.1 (latest version) btw.

```
celery beat v4.1.0 (latentcall) is starting.
OSError: [WinError 87] The parameter is incorrect
...
SystemError: <class 'OSError'> returned a result with an error set
```



Discussion:
We cannot reproduce this with the information you provided.
If you'd like, provide more information and a reproducible test case and I'll try to help.

In the meanwhile, this issue is closed.
This error occurs from: celery/platforms.py:199 (remove_if_stale)
```
try:
    os.kill(pid, 0)
except OSError as exc: # os.error as exc:
    if exc.errno == errno.ESRCH:
        print('Stale pidfile exists - Removing it.', file=sys.stderr)
        self.remove()
        return True
```

It can be fixed by catching SystemError and wiping the pidfile, e.g:
```
SystemError as exc:
    print('Stale pidfile exists - Removing it.', file=sys.stderr)
    self.remove()
    return True
```

but Im not entirely sure how this error was triggered originally as I cannot seem to reproduce it now.

can you send a PR?

Resolving patch:
diff --git a/celery/platforms.py b/celery/platforms.py
--- a/celery/platforms.py
+++ b/celery/platforms.py
@@ -202,6 +202,10 @@ def remove_if_stale(self):
                 print('Stale pidfile exists - Removing it.', file=sys.stderr)
                 self.remove()
                 return True
+        except SystemError as exc:
+            print('Stale pidfile exists - Removing it.', file=sys.stderr)
+            self.remove()
+            return True
         return False
 
     def write_pid(self):


Test patch:
Repository: celery/celery

Issue:
DeprecationWarning: Using or importing the ABCs from 'collections' is deprecated
## Checklist

- [x] 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).
- [x] I have verified that the issue exists against the `master` branch of Celery.

## Steps to reproduce
Run anything that uses `celery` under Python 3.7, verified against `celery==4.2.1`

## Expected behavior
No `DeprecationWarning` should be seen

## Actual behavior
```
.../lib/python3.7/site-packages/celery/canvas.py:12
.../lib/python3.7/site-packages/celery/canvas.py:12: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
    from collections import MutableSequence, deque
```


Discussion:
Note that the `collections.abc` module does not exist on Python 2.7.

Resolving patch:
diff --git a/celery/canvas.py b/celery/canvas.py
--- a/celery/canvas.py
+++ b/celery/canvas.py
@@ -9,7 +9,7 @@
 
 import itertools
 import operator
-from collections import MutableSequence, deque
+from collections import deque
 from copy import deepcopy
 from functools import partial as _partial
 from functools import reduce
@@ -32,6 +32,12 @@
 from celery.utils.objects import getitem_property
 from celery.utils.text import remove_repeating_from_task, truncate
 
+try:
+    from collections.abc import MutableSequence
+except ImportError:
+    # TODO: Remove this when we drop Python 2.7 support
+    from collections import MutableSequence
+
 __all__ = (
     'Signature', 'chain', 'xmap', 'xstarmap', 'chunks',
     'group', 'chord', 'signature', 'maybe_signature',


Test patch:
Repository: celery/celery

Issue:
Exception message as a string is still being unpacked
Here: https://github.com/celery/celery/blob/master/celery/backends/base.py#L282
Following code:
```
exc_msg = 'SHOULDBETOGETHER'
print(*exc_msg if isinstance(exc_msg, tuple) else exc_msg)
```
results in:
```
S H O U L D B E T O G E T H E R
```


Discussion:

Resolving patch:
diff --git a/celery/backends/base.py b/celery/backends/base.py
--- a/celery/backends/base.py
+++ b/celery/backends/base.py
@@ -279,7 +279,10 @@ def exception_to_python(self, exc):
                                                    celery.exceptions.__name__)
                 exc_msg = exc['exc_message']
                 try:
-                    exc = cls(*exc_msg if isinstance(exc_msg, tuple) else exc_msg)
+                    if isinstance(exc_msg, tuple):
+                        exc = cls(*exc_msg)
+                    else:
+                        exc = cls(exc_msg)
                 except Exception as err:  # noqa
                     exc = Exception('{}({})'.format(cls, exc_msg))
             if self.serializer in EXCEPTION_ABLE_CODECS:


Test patch:
Repository: celery/celery

Issue:
Python 3.9 compatibility issue regarding usage of threading.Thread.isAlive
<!--
Please fill this template entirely and do not erase parts of it.
We reserve the right to close without a response
bug reports which are incomplete.
-->
# Checklist
<!--
To check an item on the list replace [ ] with [x].
-->
- [x] I have verified that the issue exists against the `master` branch of Celery.
- [ ] This has already been asked to the [discussion group](https://groups.google.com/forum/#!forum/celery-users) first.
- [ ] I have read the relevant section in the
  [contribution guide](http://docs.celeryproject.org/en/latest/contributing.html#other-bugs)
  on reporting bugs.
- [x] I have checked the [issues list](https://github.com/celery/celery/issues?q=is%3Aissue+label%3A%22Issue+Type%3A+Bug+Report%22+-label%3A%22Category%3A+Documentation%22)
  for similar or identical bug reports.
- [x] I have checked the [pull requests list](https://github.com/celery/celery/pulls?q=is%3Apr+label%3A%22PR+Type%3A+Bugfix%22+-label%3A%22Category%3A+Documentation%22)
  for existing proposed fixes.
- [x] I have checked the [commit log](https://github.com/celery/celery/commits/master)
  to find out if the bug was already fixed in the master branch.
- [ ] I have included all related issues and possible duplicate issues
  in this issue (If there are none, check this box anyway).

## Mandatory Debugging Information

- [x] I have verified that the issue exists against the `master` branch of Celery.

## Optional Debugging Information

`isAlive` was deprecated and removed in Python 3.9 . Celery has the deprecation warning that will become error in Python 3.9 .

https://travis-ci.org/celery/celery/jobs/628813003#L3262-L3263

Relevant CPython PR : https://github.com/python/cpython/pull/15225



Discussion:

Resolving patch:
diff --git a/celery/utils/timer2.py b/celery/utils/timer2.py
--- a/celery/utils/timer2.py
+++ b/celery/utils/timer2.py
@@ -102,7 +102,7 @@ def stop(self):
             self.running = False
 
     def ensure_started(self):
-        if not self.running and not self.isAlive():
+        if not self.running and not self.is_alive():
             if self.on_start:
                 self.on_start(self)
             self.start()


Test patch:
Repository: celery/celery

Issue:
Support storing results in a specific schema of a PostgreSQL database
I'm using celery in a PostgreSQL environment where I only have a single database.
So I use the "schema" idiom to keep non-strongly-related data apart.
That's why I'd like to be able to store the celery task results in a different schema than the default "public" one.

Source code modification would take place in `backends/database/models.py`, both the Task & TaskSet tables and their related Sequence.
Plus of course adding a configuration hook to specify the schema name.

Thanks!



Discussion:
Sounds like a good idea, but If you want this then you would have to submit a patch using a pull request!


Resolving patch:
diff --git a/celery/app/defaults.py b/celery/app/defaults.py
--- a/celery/app/defaults.py
+++ b/celery/app/defaults.py
@@ -244,6 +244,7 @@ def __repr__(self):
         short_lived_sessions=Option(
             False, type='bool', old={'celery_result_db_short_lived_sessions'},
         ),
+        table_schemas=Option(type='dict'),
         table_names=Option(type='dict', old={'celery_result_db_tablenames'}),
     ),
     task=Namespace(
diff --git a/celery/backends/database/__init__.py b/celery/backends/database/__init__.py
--- a/celery/backends/database/__init__.py
+++ b/celery/backends/database/__init__.py
@@ -88,6 +88,10 @@ def __init__(self, dburi=None, engine_options=None, url=None, **kwargs):
             'short_lived_sessions',
             conf.database_short_lived_sessions)
 
+        schemas = conf.database_table_schemas or {}
+        self.task_cls.__table__.schema = schemas.get('task')
+        self.taskset_cls.__table__.schema = schemas.get('group')
+
         tablenames = conf.database_table_names or {}
         self.task_cls.__table__.name = tablenames.get('task',
                                                       'celery_taskmeta')


Test patch:
diff --git a/t/unit/backends/test_database.py b/t/unit/backends/test_database.py
--- a/t/unit/backends/test_database.py
+++ b/t/unit/backends/test_database.py
@@ -79,6 +79,15 @@ def test_missing_dburi_raises_ImproperlyConfigured(self):
         with pytest.raises(ImproperlyConfigured):
             DatabaseBackend(app=self.app)
 
+    def test_table_schema_config(self):
+        self.app.conf.database_table_schemas = {
+            'task': 'foo',
+            'group': 'bar',
+        }
+        tb = DatabaseBackend(self.uri, app=self.app)
+        assert tb.task_cls.__table__.schema == 'foo'
+        assert tb.taskset_cls.__table__.schema == 'bar'
+
     def test_missing_task_id_is_PENDING(self):
         tb = DatabaseBackend(self.uri, app=self.app)
         assert tb.get_state('xxx-does-not-exist') == states.PENDING
Repository: celery/celery

Issue:
[5.0.0] Celery does NOT start with both -D and -E options enabled
Hi,

I've just installed Celery 5.0.0 and noticed that it doesn't start when both `-D` and `-E` options enabled:

Only `-E` options works fine:
```
$ celery -A sample.celery worker -E

 -------------- celery@MacBook-Pro.local v5.0.0 (singularity)
--- ***** -----
-- ******* ---- Darwin-19.6.0-x86_64-i386-64bit 2020-09-24 15:59:59
- *** --- * ---
- ** ---------- [config]
- ** ---------- .> app:         sample:0x7fc944afebd0
- ** ---------- .> transport:   amqp://guest:**@192.168.0.101:5672//
- ** ---------- .> results:     disabled://
- *** --- * --- .> concurrency: 4 (prefork)
-- ******* ---- .> task events: ON
--- ***** -----
 -------------- [queues]
                .> celery           exchange=celery(direct) key=celery
```

But both `-D` and `-E` options doesn't work. It exits with exit code 0 and nothing happens...
```
$ celery -A sample.celery worker -D -E
```

**Info:**
Python 3.7.9
Celery 5.0.0 on macOS 10.15 Catalina.


Discussion:
celery has some breaking changes in v5 please check them
> celery has some breaking changes in v5 please check them

This sounds like a bug.
When detaching, all options should preserve.
I just checked it myself. This is indeed a bug.
I'm looking into it.
The problem is where we reconstruct the arguments for the detached process.
I'm on it.

Resolving patch:
diff --git a/celery/bin/worker.py b/celery/bin/worker.py
--- a/celery/bin/worker.py
+++ b/celery/bin/worker.py
@@ -302,6 +302,7 @@ def worker(ctx, hostname=None, pool_cls=None, app=None, uid=None, gid=None,
         executable = params.pop('executable')
         argv = ['-m', 'celery', 'worker']
         for arg, value in params.items():
+            arg = arg.replace("_", "-")
             if isinstance(value, bool) and value:
                 argv.append(f'--{arg}')
             else:


Test patch:
Repository: celery/celery

Issue:
Using lowercase loglevel argument like in the documentation throws error
<!--
Please fill this template entirely and do not erase parts of it.
We reserve the right to close without a response
bug reports which are incomplete.
-->
# Checklist
<!--
To check an item on the list replace [ ] with [x].
-->

- [x] I have checked the [issues list](https://github.com/celery/celery/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3A%22Category%3A+Documentation%22+)
  for similar or identical bug reports.
- [x] I have checked the [pull requests list](https://github.com/celery/celery/pulls?q=is%3Apr+label%3A%22Category%3A+Documentation%22)
  for existing proposed fixes.
- [x] I have checked the [commit log](https://github.com/celery/celery/commits/master)
  to find out if the bug was already fixed in the master branch.
- [x] I have included all related issues and possible duplicate issues in this issue
      (If there are none, check this box anyway).

## Related Issues and Possible Duplicates
<!--
Please make sure to search and mention any related issues
or possible duplicates to this issue as requested by the checklist above.

This may or may not include issues in other repositories that the Celery project
maintains or other repositories that are dependencies of Celery.

If you don't know how to mention issues, please refer to Github's documentation
on the subject: https://help.github.com/en/articles/autolinked-references-and-urls#issues-and-pull-requests
-->

#### Related Issues

- None

#### Possible Duplicates

- None

# Description
<!--
Please describe what's missing or incorrect about our documentation.
Include links and/or screenshots which will aid us to resolve the issue.
-->
When starting workers like [some examples in the documentation](https://docs.celeryproject.org/en/stable/userguide/workers.html#starting-the-worker) that uses lowercase `info` as argument to loglevel I get this error: `Error: Invalid value for '-l' / '--loglevel': invalid choice: info. (choose from DEBUG, INFO, WARNING, ERROR, CRITICAL, FATAL)`. I assume this is because of the change to Click in 5.0.

# Suggestions
<!-- Please provide us suggestions for how to fix the documentation -->
Review documentation for instances of lowercase loglevel being passed and update them to use uppercase.


Discussion:
Actually this is a bug and not a documentation bug.
I didn't intend to break it.

Resolving patch:
diff --git a/celery/bin/base.py b/celery/bin/base.py
--- a/celery/bin/base.py
+++ b/celery/bin/base.py
@@ -220,6 +220,7 @@ def __init__(self):
         super().__init__(('DEBUG', 'INFO', 'WARNING', 'ERROR', 'CRITICAL', 'FATAL'))
 
     def convert(self, value, param, ctx):
+        value = value.upper()
         value = super().convert(value, param, ctx)
         return mlevel(value)
 


Test patch:
Repository: celery/celery

Issue:
celery worker  -q --quiet seems not working with 4.4.7
Running celery 4.4.7   [not woking]
Running celery 4.4.6   [ok]
Running celery 4.4.1   [ok]


commands :

> celery -A proj worker --loglevel=info  -P eventlet --quiet
> celery -A proj worker --loglevel=info  -P eventlet -q



Discussion:
did you try 5.0.x versions?
I've recently tried this with the latest celery version (5.0.5), and the issue remains. 

The reason seems to be that in [`celery.bin.worker.worker`](https://github.com/celery/celery/blob/master/celery/bin/worker.py#L326) the `ctx.obj.quiet` option is not passed. 

The fixed code would look something like this:

```python
    worker = app.Worker(
        hostname=hostname, pool_cls=pool_cls, loglevel=loglevel,
        logfile=logfile,  # node format handled by celery.app.log.setup
        pidfile=node_format(pidfile, hostname),
        statedb=node_format(statedb, hostname),
        no_color=ctx.obj.no_color,
        quiet=ctx.obj.quiet,
        **kwargs)
```

Resolving patch:
diff --git a/celery/bin/worker.py b/celery/bin/worker.py
--- a/celery/bin/worker.py
+++ b/celery/bin/worker.py
@@ -325,6 +325,7 @@ def worker(ctx, hostname=None, pool_cls=None, app=None, uid=None, gid=None,
             pidfile=node_format(pidfile, hostname),
             statedb=node_format(statedb, hostname),
             no_color=ctx.obj.no_color,
+            quiet=ctx.obj.quiet,
             **kwargs)
         worker.start()
         return worker.exitcode


Test patch:
Repository: celery/celery

Issue:
remove misleading Task.autoregister documentation (and the unused field)
# Checklist
<!--
To check an item on the list replace [ ] with [x].
-->

- [x] I have checked the [issues list](https://github.com/celery/celery/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3A%22Category%3A+Documentation%22+)
  for similar or identical bug reports.
- [x] I have checked the [pull requests list](https://github.com/celery/celery/pulls?q=is%3Apr+label%3A%22Category%3A+Documentation%22)
  for existing proposed fixes.
- [x] I have checked the [commit log](https://github.com/celery/celery/commits/master)
  to find out if the bug was already fixed in the master branch.
- [x] I have included all related issues and possible duplicate issues in this issue
      (If there are none, check this box anyway).

## Related Issues and Possible Duplicates
<!--
Please make sure to search and mention any related issues
or possible duplicates to this issue as requested by the checklist above.

This may or may not include issues in other repositories that the Celery project
maintains or other repositories that are dependencies of Celery.

If you don't know how to mention issues, please refer to Github's documentation
on the subject: https://help.github.com/en/articles/autolinked-references-and-urls#issues-and-pull-requests
-->

#### Related Issues

- None

#### Possible Duplicates

- None

# Description
<!--
Please describe what's missing or incorrect about our documentation.
Include links and/or screenshots which will aid us to resolve the issue.
-->
The documentation for celery.app.Task describes an attribute `autoregister` and implies that if set to true the task will be registered automatically ("If disabled this task won’t be registered automatically."). However this feature has sadly been removed with the celery 4.0 release.
https://docs.celeryproject.org/en/latest/reference/celery.app.task.html#autoregister

The attribute doesn't appear to be used anywhere, a quick search of the code base found only one other occurrence in the changelog for v1.0.

# Suggestions
Either re-add the automatic registration for class based tasks, remove the field or clarify the documentation.



Discussion:
would you mind sending a PR to clean this up?

Resolving patch:
diff --git a/celery/app/task.py b/celery/app/task.py
--- a/celery/app/task.py
+++ b/celery/app/task.py
@@ -219,9 +219,6 @@ class Task:
     #: The result store backend used for this task.
     backend = None
 
-    #: If disabled this task won't be registered automatically.
-    autoregister = True
-
     #: If enabled the task will report its status as 'started' when the task
     #: is executed by a worker.  Disabled by default as the normal behavior
     #: is to not report that level of granularity.  Tasks are either pending,


Test patch: