Failed to parse comment sent via email

Bug #708258 reported by Guilherme Salgado
28
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Triaged
High
Unassigned

Bug Description

On https://code.launchpad.net/~doanac/linaro-image-tools/slash-proc-spam-version2/+merge/47436 I sent an email with some comments (https://code.launchpad.net/~doanac/linaro-image-tools/slash-proc-spam-version2/+merge/47436/comments/104880/+reply) but it was miss-parsed and only the first paragraph was included in the actual mp comment. I then resent the email (this time with an extra sentence at the top) but it was miss-parsed again, so I guess this can be reproduced easily. Just ping me if you'd like the raw email to reproduce it.

Changed in launchpad:
status: New → Triaged
importance: Undecided → High
tags: added: code-review email
Curtis Hovey (sinzui)
summary: - Failed to parse merge proposal comment sent via email
+ Failed to parse comment sent via email
tags: added: questions
Revision history for this message
Curtis Hovey (sinzui) wrote :

This also happened in answers. Only the first paragraph was store and it was quoted.

MessageSet is using the standard mime walker rules to select a text part. I do not see anything odd in question message to cause the unquoted part of the first text/part to be dropped. The message should also be stored in the the librarian, it may be possible to look at the FileAlias, Message and MessageChunk to see if something was lost or corrupted.

Revision history for this message
Robert Collins (lifeless) wrote :

Could we get the message attached to the bug please?

Changed in launchpad:
status: Triaged → Incomplete
Revision history for this message
Guilherme Salgado (salgado) wrote :
Changed in launchpad:
status: Incomplete → Triaged
Revision history for this message
Curtis Hovey (sinzui) wrote :

This looks something-like an smtp conversation:

{{{
On Wed, 2011-01-26 at 18:58 +0000, Andy Doan wrote:
> On 01/26/2011 07:13 AM, James Westby wrote:
> > The thing to be careful of here is reporting errors. If one fails and
> > then another is run it can fail with a knock-on error. We want both to
> > be reported, not just the last, as it can save hours of head scratching=
.

This won't happen because on a try/finally the exception is re-raised
after the finally block is executed. I don't know what I had in mind
when I made my comment that the try/finally in run_local_atexit_funcs()
would make sure all cleanup functions executed.
}}}

Notice the newline, dot, newline newline combination. I wonder if this is actually an error in sending rather than receiving?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.