I've seen this once or twice before, but this just happened recently. In bug 78720, a person just attached the same file multiple times, really qucikly. The first mail containted that comment. The second cnotained that comment + the second patch The third mail containted that comment + the second comment + the thrid comment And so on. This happens because there are no locks arruond processmail, so there is a race condition between reading delta_ts, getting the changes, and writing delta_ts. This means that changes can be snent out more than once. Since processmail sends out all data, I don't think mails can be missed, but I'm not sure. I'll look at this when I redo locking, I guess. Another table level write lock on the bugs table will be fun.

Changing default owner of Email Notifications component to JayPee, a.k.a. J. Paul Reed (preed@sigkill.com). Jake will be offline for a few months.

*** Bug 157007 has been marked as a duplicate of this bug. ***

ok, processmail got moved into Bugzilla/BugMail.pm. That have any effect on this? Probably not, but thought it safe to ask.

Probably somewhat... this is on my radar to fix after the fun that is 84876.

This looks like a dupe to me. JP: can you verify? Gerv *** This bug has been marked as a duplicate of 179351 ***

not a dupe. this is a different issue.

Pushing out bugs that aren't blockers. If someone's working on one of these, we can move it back.

Making bug 84876 block this, since it isn't too sane to hack the current bugmail system any further.

Bug 84876 is now a meta-bug, once again. So this should proably be worked on. JayPee, I'm going to assume that you're not working on this and move it back to email-notifications@bugzilla.bugs. Feel free to take it back, though.

This doesn't seem like a critical issue to me, or even major. It's certainly annoying when it happens, but I don't think it's a super-common occurrence.

We certainly don't want to lock any table while processing emails. That's the purpose of bug 181059 and bug 284184. A better solution would be to inform BugMail.pm that a process is already running. I could imagine a new 'email_queue' table of the form: id # ID of the process (Primary Key, auto-increment) bug_id # Bug ID start_time # Start time end_time # End time The process 'id' is currently sending all emails from bug 'bug_id' between 'start_time' and 'end_time'. As soon as the process is done, this entry is removed and bugs.lastdiffed is updated to the corresponding email_queue.end_time. If a new process for a given bug is created before the previous one (for the same bug) is done, 'start_time' is equal to 'end_time' of the previous process, else 'start_time' equals bugs.lastdiffed. In all cases, 'end_time' is equal to 'bugs.delta_ts'. Maybe this 'email_queue' table would be the only one which needs to be locked, but certainly not any other table. Comments?

One proposal has been to store the mails in a table, then process them externally via cron every so often (as an option only)