subscribed to a code branch, but did not receive most updates

Update since revision 24:
Received: 24, 30
Did not receive: 25, 26, 27, 28, 29

(After revision 39) I have unsubscribed and re-subscribed myself, in case there was something wrong. I'll report soon, as soon as I have some changes to push :)

After revision 39:

Received: 40, 42
Did not receive: 41

A joyful update!! I have received revisions from 42 until 47 successfully. I think this is solved.
It seems that it just needed me to Unsubscribe and Subscribe again. :)

Setting as "Incomplete" (in case I do not receive emails in the future)

I think it's fixed, settings as "Invalid"

Back to square one.
Received email for revisions: 42 up to 51 (included), 60, 64, 66
Did not receive email for revisions: 52 up to 59 (included), 61 up to 63 (included), 65, 67

I think I have discovered why this happens. It seems to be connected to the fact that when I push bzr revisions, any changes to .po/.pot files are scanned and processed/submitted to rosetta project for translation import.

All emails (or most of them) that I haven't received have changes to .po/.pot files. I don't think it's a coincidence:

$ bzr log -v i18n/ locale/ | grep revno | sed -e 's/revno: //' | xargs
69 67 66 65 63 62 61 60 59 58 57 56 55 54 53 52 47 45 44 41 40 39 38 37 35 34 33 32 31 30 29 28 27 26 25 22 20 18 17 13 12 11 8 7 5 4 1

Can someone check:
- what happens when I push .po/.pot files from bzr?
- if there is something "holding up" the emails while .po/.pot changes are being sent to rosetta through bzr?

I've discussed this with Aaron Bentley: it's likely a problem with code starting jobs.

Btw, Savvas, thanks for this much investigative work: I am pretty sure this will help nail down the problem, and that's always appreciated :)

> Btw, Savvas, thanks for this much investigative work: I am pretty sure
> this will help nail down the problem, and that's always appreciated :)

Thanks, I surely hope it's enough!

Since jml modified the scanner to support this, he'd have the best idea whether the bug is here.

Assigning to Aaron to chase.

I've pulled the DB records, and it looks like a bunch of the RevisionMailJobs are failing. I can't find a corresponding OOPS. Here's a list of the revnos of RevisionAddedJobs, with "2" indicating success, and "3" indicating failure.

3 - 3: 2
4 - 4: 3
5 - 9: 3
10 - 10: 2
11 - 11: 3
12 - 12: 3
13 - 13: 3
14 - 14: 2
15 - 15: 2
16 - 17: 3
18 - 20: 3
21 - 21: 2
22 - 22: 3
23 - 23: 2
24 - 24: 2
25 - 25: 3
26 - 26: 3
27 - 27: 3
28 - 28: 3
29 - 29: 3
30 - 30: 2
31 - 32: 3
33 - 33: 3
34 - 34: 3
35 - 35: 3
36 - 36: 2
37 - 37: 3
38 - 38: 3
39 - 39: 3
40 - 40: 2
41 - 41: 3
42 - 42: 2
43 - 43: 2
44 - 44: 2
45 - 45: 2
46 - 46: 2
47 - 47: 2
48 - 49: 2
50 - 50: 2
51 - 54: 3
55 - 56: 3
57 - 58: 3
59 - 59: 3
60 - 61: 3
62 - 63: 3
64 - 64: 2
65 - 65: 3
66 - 66: 2
67 - 67: 3

This does not match up neatly with the user reports. For example, the job handling revno 51-54 failed, but apparently the user received 51. The job handling 60-61 failed, but the user received 60.

It seems that the jobs for ranges of revisions rarely succeed, but the job for 48 - 49 did.

I may have accidentally misreported them. Here are the revisions I have in my gmail cummulatively:
70 68 66 64 60 51 50 48 49 47 46 45 44 43 42 40 36 30 24 23 21 18 19 16 15 14 10 3

Thanks. I think for revisions 51 and 60, the only explanation is that the first email of the job succeeded, and the second failed.

I think it has to do with both facts that a) the branch sends
translations to rosetta and b) when there are pairs.

- Revisions with commits to "i18n" and "locale" (they have or had .po
and .pot files):
69 67 66 65 63 62 61 60 59 58 57 56 55 54 53 52 47 45 44 41 40 39 38
37 35 34 33 32 31 30 29 28 27 26 25 22 20 18 17 13 12 11 8 7 5 4 1

- Received revisions:
70 68 66 64 60 51 50 48 49 47 46 45 44 43 42 40 36 30 24 23 21 18 19
16 15 14 10 3

- Reported as failed:
* Singles: 11 12 13 22 25 26 27 28 29 33 34 35 37 38 39 41 59 65 67
* As pairs: 16-17 18-20 31-32 51-54 55-56 57-58 60-61 62-63

From my point of view:

- From "51-54":
I received 51.
52-54 failed (did not receive them).
52-54 contained changes to .po/.pot files (translations).
Cumulative report: "3" (failed).

- From "18-20":
I received 18 and 19.
19 and 20 failed.
18 and 20 had translations.
Cumulative report: "3" (failed)

- From "16-17":
I received 16.
17 failed.
17 had changes to translations.
Cumulative report: "3" (failed)

See the pattern?

> I received 18 and 19.
> 19 and 20 failed.

Correction:
I received 18 and 19.
20 failed.

When I said I couldn't find a corresponding OOPS, it was because I was looking in the wrong place. There are plenty of OOPS reports for that day. Most of them are due to diffs containing high-bit characters. That would explain the correspondence between translation file changes and missing revisions, since translation files typically contain high-bit characters. I conclude this is a dupe of bug #371469. Fixes for this bug have already been landed, and will take effect when the next release of Launchpad is rolled out.