-
Notifications
You must be signed in to change notification settings - Fork 194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
If a malformed message gets into Rabbit, Celery worker fails to start #277
Comments
It cannot leave the message unacknowledged, as that means it will reduce the prefetch limit. The only other way it could deal with it is to log the event and discard the message, as requeueing it will cause a loop. |
@ask That works for me. |
Correction! This bug is actually in amqp/serialization.py (separate project). The version I have (1.4.9) assumes all headers are UTF-8 encoded with this code: def read_longstr(self):
"""Read a string that's up to 2**32 bytes.
The encoding isn't specified in the AMQP spec, so
assume it's utf-8
"""
self.bitcount = self.bits = 0
slen = unpack('>I', self.input.read(4))[0]
return self.input.read(slen).decode('utf-8') But that is not a safe assumption, as header values are totally unconstrained. They could be binary data, for example. Which is why the |
Here's a minimal snippet that can repro this crash and put your Celery worker into an unrecoverable loop: my_task.apply_async(args=['test'], headers={'foo': '\x8d'}) The
I would love to submit a PR to fix this, but I'm not super clear on what version of py-amqp to work on. What do you recommend? Once I know which version to work on, I'm thinking about modifying the py-amqp serialization module to ignore header values that cannot be decoded with UTF-8. |
Prior to this commit, a non-UTF8 encoded header string would cause an un caught UnicodeDecodeError, which would cause an unrecoverable Celery error. Now we log non-UTF8 header strings (names and values), and continue processing. Closes https://github.com/celery/celery/issues/2873
Never mind, I found the 1.4 branch. Here's my PR: #78 |
Hi! I'm having the same issue with Celery 4.1.0 and kombu 4.1.0. Any idea? |
can you cleanly apply the patch on pyamqp? |
The bug is still present, it does not require a feedback but a simple fix... |
could you tell which versions of celery you are using and facing this issue? |
If a publisher manages to publish a corrupted, non-UTF8 decodable message into Rabbit, the Celery worker will fail to start. I propose that it should instead leave the message unacknowledged, log the error, and continue working on other messages.
Here's an example stack trace when this happens:
Versions:
Celery: 3.1.16
Kombu: 3.0.23
Using
pyamqp://
The text was updated successfully, but these errors were encountered: