duointeractive / sea-cucumber Goto Github PK

Instead of catching all the exceptions either to log or retry, having an option for users to customize how they want to handle the email exceptions.

I have just run into an issue sending attachments. I have not had time to investigate exactly where this problem should be fixed, but I am posting it here in the mean time because this is probably something the email backend can address.

I am using sea-cucumber for my email backend with the SQS celery backend.

When trying to send an email with an attachment I get the following:

[2013-11-26 15:50:42,364: ERROR/MainProcess] Task foo.task_foo[arg_foo] raised exception: SQSError: 413 Request Entity Too Large
None
Traceback (most recent call last):
  File "/opt/python/run/venv/lib/python2.6/site-packages/celery/task/trace.py", line 224, in trace_task
    R = retval = fun(*args, **kwargs)
  File "/path/to/foo/tasks.py", line 95, in foo_method
    foo()
  File "/path/to/foo/models.py", line 622, in foo2_method
    msg.send()
  File "/opt/python/run/venv/lib/python2.6/site-packages/django/core/mail/message.py", line 248, in send
    return self.get_connection(fail_silently).send_messages([self])
  File "/opt/python/run/venv/lib/python2.6/site-packages/seacucumber/backend.py", line 33, in send_messages
    message.message().as_string().decode('utf8'),
  File "/opt/python/run/venv/lib/python2.6/site-packages/celery/app/task.py", line 357, in delay
    return self.apply_async(args, kwargs)
  File "/opt/python/run/venv/lib/python2.6/site-packages/celery/app/task.py", line 478, in apply_async
    **options)
  File "/opt/python/run/venv/lib/python2.6/site-packages/celery/app/amqp.py", line 229, in publish_task
    **kwargs)
  File "/opt/python/run/venv/lib/python2.6/site-packages/kombu/messaging.py", line 164, in publish
    routing_key, mandatory, immediate, exchange, declare)
  File "/opt/python/run/venv/lib/python2.6/site-packages/kombu/connection.py", line 423, in _ensured
    return fun(*args, **kwargs)
  File "/opt/python/run/venv/lib/python2.6/site-packages/kombu/messaging.py", line 179, in _publish
    mandatory=mandatory, immediate=immediate,
  File "/opt/python/run/venv/lib/python2.6/site-packages/kombu/transport/virtual/__init__.py", line 463, in basic_publish
    exchange, routing_key, **kwargs)
  File "/opt/python/run/venv/lib/python2.6/site-packages/kombu/transport/virtual/exchange.py", line 59, in deliver
    _put(queue, message, **kwargs)
  File "/opt/python/run/venv/lib/python2.6/site-packages/kombu/transport/SQS.py", line 219, in _put
    q.write(m)
  File "/opt/python/run/venv/lib/python2.6/site-packages/boto/sqs/queue.py", line 220, in write
    delay_seconds)
  File "/opt/python/run/venv/lib/python2.6/site-packages/boto/sqs/connection.py", line 249, in send_message
    queue.id, verb='POST')
  File "/opt/python/run/venv/lib/python2.6/site-packages/boto/connection.py", line 1069, in get_object
    raise self.ResponseError(response.status, response.reason, body)
SQSError: SQSError: 413 Request Entity Too Large
None

My initial thoughts are that the attachments could be stored as a reference to an s3 object when serialized. From http://aws.amazon.com/sqs/faqs/#How_much_and_what_kind_of_data_can_go_in_a_message it looks like "Amazon SQS messages can contain up to 256 KB of text data"

Once I investigate further I will report back. In the mean time, if anyone has faced this already, please let me know.

It would be nice if all of the available settings were listed together in the README. I only found CUCUMBER_SES_REGION_NAME and its default of AWS_SES_REGION_NAME because I checked closed tickets before submitting one and saw https://github.com/duointeractive/sea-cucumber/pull/16/files

If there is already a list somewhere, I apologize. I read through everything I could find, but I was in a hurry.

Received unregistered task of type 'seacucumber.tasks.SendEmailTask'.
The message has been ignored and discarded.

Did you remember to import the module containing this task?
Or maybe you are using relative imports?
Please see http://bit.ly/gLye1c for more information.

The full contents of the message body was:
{'utc': True, 'chord': None, 'args': ('****@****.com', [u'****@****.com'], u'Content-Type: multipart/alternative;\n boundary="===============6467111035107845744=="\nMIME-Version: 1.0\nSubject: Notification\nFrom: [email protected]\nTo: ****@****.com\nDate: Thu, 20 Feb 2014 14:48:14 -0000\nMessage-ID: <[email protected]>\n\n--===============6467111035107845744==\nMIME-Version: 1.0\nContent-Type: text/plain; charset="utf-8"\nContent-Transfer-Encoding: 7bit\n\nmessage... (1351b)

Traceback (most recent call last):
  File "/home/****/projects/****/local/lib/python2.7/site-packages/celery/worker/consumer.py", line 455, in on_task_received
    strategies[name](message, body,
KeyError: 'seacucumber.tasks.SendEmailTask'

A pip freeze shows django-celery==3.1.9, celery==3.1.9, seacucumber==1.5.1, django-ses==0.4.1, Django==1.6.2, boto=2.25.0, anyjson==0.3.3 (not sure if anyjson is relevant, but I see it referenced elsewhere).

Of note, I was using SES and Celery before installing seacucumber, and everything was happy. Other, non-seacucumber-related tasks work perfectly with or without seacucumber installed.

Am I missing something?

Edit: More detail -- just wanted to point out that this happens even with a generic django.core.mail.send_mail test. Works without seacucumber, throws the above referenced error with seacucumber set as the backend.

I ran ses_usage before sending any emails and got this exception.

After sending a few emails it managed to display today's data
but raised the same exception when trying to display yesterday's
data.

python2.7 manage.py ses_usage
--- SES Quota ---
24 Hour Quota: 200.0
Sent (Last 24 hours): 0.0
Max sending rate: 1.0/sec
--- Current Day: 7/5 ---
Traceback (most recent call last):
File "../seacucumber/management/commands/ses_usage.py", line 22, in handle
self._print_daily_stats(conn)
File "../seacucumber/management/commands/ses_usage.py", line 61, in _print_daily_stats
print " Delivery attempts: %s" % day['DeliveryAttempts']
KeyError: 'DeliveryAttempts'

Hello, I'm using celery (3.1.23) with Django (1.9) and I had to specify CUCUMBER_ROUTE_QUEUE = 'celery' since the default is empty string (https://github.com/duointeractive/sea-cucumber/blob/master/seacucumber/backend.py#L31), which leads to a silent fail.

There are two options:

• It should be explained in the readme that CUCUMBER_ROUTE_QUEUE should be specified.
• The default queue should be changed from empty string to celery.

Kindly let me know which one you would prefer, and why, and I can open a pull request with the change. Thank you for your time.

Amazon SES also implements per day email limit. Any way to respect that?

Anyone come across an issue where if you hit your daily send quota, seacucumber sends the error notification email via seacucumber, which leads to recursive errors?

Add a management command to cause AWS SES to send a verification email to a given address. Something like this:

./manage.py ses_request_verify [email protected]

Up to the user to read and follow the directions in SES's email, of course.

Hi,

I just tried to use this package on a project and apparently it crashes with emails containing UTF-8 Characters.

It crashes at this line:

message.message().as_string().decode('utf8')

as_string() function is unable to decode utf-8 character.

UnicodeEncodeError: 'ascii' codec can't encode character u'\u2022' in position 5330: ordinal not in range(128)

How did you solve this in your projects?

Thank you.

I have it set way below my AWS limit but I am getting errors about exceeding the AWS sending limit. Anyone else experience something similar?

Noticed this in the celery source (3.12) when dropping seacucumber into our solution today:

celery.task.base
~~~~~~~~~~~~~~~~

The task implementation has been moved to :mod:`celery.app.task`.

This contains the backward compatible Task class used in the old API,
and shouldn't be used in new applications.

Deprecated Task base class.

Modern applications should use :class:`celery.Task` instead.

Are you planning to update in the near future or should we fork?

Is there a plan to support python 3?