I know we sent not only duplicates, but in sometimes as many as 6
copies of an email to a customer because of the mail.Send() error
(like the parent poster, our emails are sent in a task).
What is the status of this error?
On Oct 13, 7:44 am, Jamie H ja...@mhztech.com wrote:
Googlers,
I'm
We're aware of issues with mail.send() and exceptions. Ryan, do you know
what percentage of calls this is happening to you for? Can you identify a
pattern in when these errors occur?
There is a workaround, but it's a bit of an ugly one. I'd like to test it
out before I recommend it. From a high
Googlers,
I'm wondering if anything else has been rolled out to fix this issue?
I sent several hundred emails this morning and received 0 errors.
Maybe a fluke? Maybe it's fixed?
On Oct 11, 8:21 pm, ego008 ego...@gmail.com wrote:
I here is well done http://gaefons.appspot.com/
2010/10/12
The 100 email scenario is where Ikai's first solution works best. You
can put flags in memcache for the first 80, so you know not to send
them again. This is a pretty good solution to this problem - so if you
*want* to send multiple emails per task, then using Ikai's solution
doesn't really leave
It seems the author is saying that he only sends one email per task,
so the only 'email sent' flag to stick in memcache is the one that is
occurring when the exception is raised. I'm not sure that solution
will work - how can he know if an email has been sent successfully
when the mail API is
I've seen another solution where you BCC your application and use that to
mark the flag as successful or not.
On Wed, Apr 14, 2010 at 6:19 AM, hawkett hawk...@gmail.com wrote:
It seems the author is saying that he only sends one email per task,
so the only 'email sent' flag to stick in
Sounds like it would reliably set the flag, but probably not soon
enough (at least in some situations) to beat the task queue retry
On Apr 14, 7:14 pm, Ikai L (Google) ika...@google.com wrote:
I've seen another solution where you BCC your application and use that to
mark the flag as
Heyo,
I'm having similar issues. Have either of you had any success figuring
this out?
My concern isn't over whether I can catch the exception or not, but
rather knowing whether we can assume that the email message was
actually delivered when this exception is produced. I assume not,
though in
i hadn't tried that, but i did get it to work once i used the correct
import statement...
from google.appengine.runtime import apiproxy_errors
On Oct 29, 5:33 pm, Joshua Smith joshuaesm...@charter.net wrote:
Did you try catching all exceptions?
except:
logging.exception(...
On Oct
I'm seeing quite a few as well. Although I do find that the emails get
delivered regardless.
On Oct 29, 11:22 am, Joshua Smith joshuaesm...@charter.net wrote:
We're getting a surprising number of these errors:
The API call mail.Send() took too long to respond and was cancelled.
This is
Well that's not cool.
Task queue did the same thing: Threw an exception, even though it
actually queued the task. Perhaps Google is confused about what an
exception is.
Nick: How can I tell if the email was sent? I'd hate to blast a bunch
of duplicate emails just because of some bogus
To add to this problem is the fact that I can't adequately catch the
exception and avoid the re-queueing of the task. More on that here...
http://groups.google.com/group/google-appengine/browse_thread/thread/288966daaecf3d05/c70bfd5b7f3307ef#c70bfd5b7f3307ef
On Oct 29, 2:17 pm, Joshua Smith
Did you try catching all exceptions?
except:
logging.exception(...
On Oct 29, 2009, at 5:36 PM, Greg Tracy wrote:
To add to this problem is the fact that I can't adequately catch the
exception and avoid the re-queueing of the task. More on that here...
13 matches
Mail list logo