This is purely a race condition between the commit to the remote db server which writes the Email row and the task delegation path.  We've had the task start executing before the transaction commits, so some retry logic would be necessary.  I'm not sure if kevin put in a long enough delay, but I think there should be one.




On Aug 22, 2013, at 2:21 PM, brianhw <notifications@github.com> wrote:

> In lms/djangoapps/bulk_email/tasks.py:
> 
> > +
> > +    `to_option` is {'myself', 'staff', or 'all'}
> > +
> > +    Returns the number of batches (workers) kicked off.
> > +    """
> > +    try:
> > +        course = get_course_by_id(course_id)
> > +    except Http404 as exc:
> > +        log.error("get_course_by_id failed: " + exc.args[0])
> > +        raise Exception("get_course_by_id failed: " + exc.args[0])
> > +
> > +    try:
> > +        CourseEmail.objects.get(hash=hash_for_msg)
> > +    except CourseEmail.DoesNotExist as exc:
> > +        log.warning("Failed to get CourseEmail with hash %s, retry %d", hash_for_msg, current_task.request.retries)
> > +        raise delegate_email_batches.retry(arg=[hash_for_msg, to_option, course_id, course_url, user_id], exc=exc)
> Is there a reason why we expect a retry to work here, if the CourseEmail didn't exist the first time?
> 
> —
> Reply to this email directly or view it on GitHub.
>