Fwd: Mailman | The unsubscribe process using the -leave address does not work because of an `assert` in the code (#310)
@abompard I don't know what's going here. I received the notice below from GitLab. I tried to go there to comment that this looks like a duplicate or at least very similar to https://gitlab.com/mailman/mailman/issues/294 which was fixed about 3 weeks ago, but GitLab gives me a 404 and says there is no issue #310.
-------- Forwarded Message --------
Subject: Mailman | The unsubscribe process using the -leave
address does not work because of an assert in the code (#310)
Date: Thu, 09 Feb 2017 10:31:52 +0000
From: Aurélien Bompard gitlab@mg.gitlab.com
Reply-To: mailman / Mailman
incoming+36519312af637e6be0deecee3e4f348b@gitlab.com
To: mark@msapiro.net
GitLab
Here's the situation that I have confirmed on my servers:
- a members sends an email to the |-leave| address to unsubscribe
- they recieve a confirmation email
- they reply to this email-
- |SubscriptionManager.confirm()| get called, the |UnSubscriptionWorkflow| gets restored and run, the goodbye email gets sent to the user.
- at the end of the |UnSubscriptionWorkflow| in |._step_do_unsubscription()|, the |.member| attribute gets set to None
- the |.confirm()| command returns |workflow.token|, |workflow.token_owner|, and |workflow.member| to the caller
- on line 56, |commands.eml_confirm.Confirm| has an |assert member is not None|, which causes an AssertionError. As a result, the database transaction is rollbacked and the unsubscription is forgotten.
I suspect this |assert| comes from the time where the -confirm command was only used for subscription confirmations, not unsubscription confirmation. Removing it solves the problem.
I think this is important and simple enough to fix it for 3.1.
— Reply to this email directly or view it on GitLab https://gitlab.com/mailman/mailman/issues/310.
On Feb 09, 2017, at 07:38 AM, Mark Sapiro wrote:
@abompard I don't know what's going here. I received the notice below from GitLab. I tried to go there to comment that this looks like a duplicate or at least very similar to https://gitlab.com/mailman/mailman/issues/294 which was fixed about 3 weeks ago, but GitLab gives me a 404 and says there is no issue #310.
I'm not positive, but I have a theory. GL says there are only 309 issues of both closed and open state on the mailman project. It's possible that this one got caught up in their database incident:
https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/
and the email was queued up before then, since it's date of 09-Feb-2017 is well after the incident was resolved. It's known that about 6 hours of issues, MRs, comments, etc. were irretrievably lost.
I did move an issue from mailman to postorius, but I believe that what happens in that case is that a new issue is created in the target project (with duplicate contents but a different issue number in sequence with the target), while the source project's issue just gets closed. I can't find that one right now to confirm.
Anyway, Aurelien would probably need to say whether his issue falls within the timeline of the GL database snafu or not. I think there's no option but to try to re-submit the issue if that's the case.
Cheers, -Barry
On 02/09/2017 08:28 AM, Barry Warsaw wrote:
I'm not positive, but I have a theory. GL says there are only 309 issues of both closed and open state on the mailman project. It's possible that this one got caught up in their database incident:
Except that Issue #309 was opened yesterday, well after the GL database incident. So I would think that Issue #310 would have to have been created after that.
It seems that something erased or lost issue #310 after it was posted, but I don't think it's related to the database rollback.
On Feb 09, 2017, at 08:39 AM, Mark Sapiro wrote:
Except that Issue #309 was opened yesterday, well after the GL database incident. So I would think that Issue #310 would have to have been created after that.
It seems that something erased or lost issue #310 after it was posted, but I don't think it's related to the database rollback.
Oh that's scary then! I'll see if I can track someone at Gitlab down.
-Barry
participants (2)
-
Barry Warsaw -
Mark Sapiro