Odd mailing list resync behavior
Bug #215118 reported by
Barry Warsaw
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Launchpad itself |
Fix Released
|
High
|
Barry Warsaw | ||
Bug Description
Now that we fixed bug 208431, we're still seeing some strange behaviors. We have a number of lists with status = 6 (FAILED) as per staging queries, yet according to the mailman logs, these lists are trying to resync. Only status = 4 (CONSTRUCTING) and status = 9 (UPDATING) should try to resync.
Furthermore, there is no trace of the FAILED lists on mailman. There are no log entries about their construction or failure, as there should be. The lists themselves don't exist either, so how did their status get to be 6?
Revision history for this message
| Barry Warsaw (barry) wrote | #1 |
Revision history for this message
| Barry Warsaw (barry) wrote | #2 |
| Changed in launchpad: | |
| assignee: | nobody → barry |
| importance: | Undecided → High |
| milestone: | none → 1.2.4 |
| status: | New → Confirmed |
| Changed in launchpad: | |
| status: | Confirmed → In Progress |
Revision history for this message
| Barry Warsaw (barry) wrote | #3 |
Revision history for this message
| Barry Warsaw (barry) wrote | #4 |
| Changed in launchpad: | |
| status: | In Progress → Fix Committed |
| Changed in launchpad: | |
| status: | Fix Committed → Fix Released |
To post a comment you must log in.
Okay, sanity prevails. The status of these lists is 4 on lpnet, which makes sense. I have no idea why status = 6 on staging, but ignoring that, it should be fairly straightforward to fix this bug. During resync, on Mailman, if status = 4 and the list doesn't exist, just create it.